150 likes | 261 Views
Synchronization and Sequencing for high level applications. Julian Lewis AB/CO/HT. SPS Bkt 1 Rng 1 2 Batch. PS Batch 1. PS Batch 2. PSB 1.1. PSB 1.2. PSB 2.1. PSB 2.2. Synchronization: How it works. SC composition. All timing cables. t mean. Equipment. The DSC timing cable.
E N D
Synchronization and Sequencing for high level applications Julian Lewis AB/CO/HT
SPS Bkt 1 Rng 1 2 Batch PS Batch 1 PS Batch 2 PSB 1.1 PSB 1.2 PSB 2.1 PSB 2.2 Synchronization: How it works SC composition All timing cables t mean Equipment The DSC timing cable Events t=0 t=K Arrival Time From DMCRPLS via UDP From DSC via MW Synchronization event + Telegram & Time stamps + Flags: StBm StCy… Acquisition data + Acquisition time stamp JAPC C/C++ TGM MW From DMCRPLS via GMT & CTRI LHC StBm StCy Missed !! EnBm EnCy OK Data
Application events Flags Beam time stamp 00:Fields : 0x807fffff 01:EvtId : 211 02:Catags : 0x0000061e: ------ StrCyc TgmRdy BpRdy EndCyc ------ ------ ------ StrtBm EndBm 03:Machine: PSB 04:BPTime : Tue-22/Mar/2005 10:24:58.917 (1111483498 S) (917 Ms) 06:SeqNo : 1512866 07:ChsId : 1111157523 Fri-18/Mar/2005 15:52:03 08:Level : 1 09:BmState: Spare 10:BmId : 12370 11:BmIns : 5 12:BmTime : Tue-22/Mar/2005 10:24:58.917 (1111483498 S) (917 Ms) 14:CycId : 2: ISOGPS 15:CycInst: 2 16:CycTime: Tue-22/Mar/2005 10:24:58.917 (1111483498 S) (917 Ms) 18:BPInst : 5 19:AqnTime: Tue-22/Mar/2005 10:24:58.917 (1111483498 S) (917 Ms) 21:EvtTime: Tue-22/Mar/2005 10:24:58.917 (1111483498 S) (917 Ms) 31:Telegm : 2 1 3 1 0 0 4205 5 ff 586c bc 5 18 1 2 1 0 78 40 fb 1 1 578 3052 4 4 4 4 4 1 Acquisition time stamp Telegram
Latency for CTRI on pcgw Ker 2.6 Time of 1PPS Interrupt: Mon-18/Apr/2005 15:56:10.0000072500 Time of call to driver: Mon-18/Apr/2005 15:56:10.0000187000 Latency of driver call: 0.0000114500 Seconds Average time: 500 calls: 0.0000115971 Seconds Max and Min: [0.0000213500 - 0.0000111000] Time of 1PPS Interrupt: Mon-18/Apr/2005 16:05:38.0000068000 Time of call to driver: Mon-18/Apr/2005 16:05:38.0000216250 Latency of driver call: 0.0000148250 Seconds Average time: 265 call: 0.0000514722 Seconds Max and Min: [0.0024420250 - 0.0000111500] PPS interrupt Wait PPS Read Time Compute latency D r I v e r Wait PPS Read Time Compute latency Wait PPS Read Time Compute latency Wait PPS Read Time Compute latency 2.5ms very loaded CTRI ~0.025ms unloaded
Producing events CBCM Programs BCD/Beams/Cycles etc … To non critical systems in CCC, offices and labs Events DTM/UDP Reflective memory Event pusher Mission critical servers and work stations Events via GMT CTG CTRI Events UDP CCC For CNGS Grand Saso GMT Timing cables PSB/LEI/CPS/ADE/SPS/LHC
CBCM – Brain critical interactions CRITICAL Post-Mortem Dump Bucket Ring Intensity Batches Start-Ramp Ready Pilot One-Shot Commit CBCM LHC BRAIN Control Data + Stamps from MW Events Timing
Added Value (1) • All telegrams for all accelerators are available. • Acquisition data to cycle correlation. • Cycle to Beam & BCD correlation. • Missing or late MW data detection. • Better handling of errors during an LHC fill allowing quicker response, and less lost super-cycles. • Makes ON-Change subscriptions possible. • No need to subscribe to telegrams, so MW is less stressed, gets on with essential job. • Less loading of the controls network. • Precise: (250us - 2.5ms scheduler) using a CTRI. • Reliable: CTRI unaffected by network loading. • Works without MW - subscription (Pull).
Added Value (2) • Backwards compatible with PS complex. • Real time events can be added as needed. EG Post-mortem, BIC, Commit-Transactions. • Works everywhere. (Offices + Technical network). • Client code is unaware of the event source. • Scalable, IE unaffected by the number of clients. • Allows modification of telegram description on the fly.
Affect of installing a CTRI on a server or workstation • Client software, there is zero effect. • Work station configuration, there is zero effect. • Hardware, the CTRI cards are reliable, if they don’t work we are in real trouble ! • Installed like this • Linux DSCs • insmod /ps/dsc/mcr/L86/`uname -R`/ctr/CtrModule.ko • Linux servers and work stations • insmod /ps/mcr/`uname -R`/ctr/CtrModule.ko
Cost & Maintenance • 150M Cable ( < 1000 Sf) • 4 Timing Fan outs ( < 4 x 100 Sf) • GMT Cannon-Cables as needed (25 Sf each) • CTRI Cards as needed (~800 Sf each) • Maintenance of Linux driver: No extra cost • Diagnostics: Available, ctrtest is a lot easier to use than DTM Diagnostics. Saves costs.
Conclusion: Using CTRIs • Installing CTRI cards in critical systems is cheap, easy to do, and greatly increases both run time reliability and timing precision. • No effect on clients or platform configuration. • Increases the chances of detecting errors early, and hence reduces the number of lost super-cycles during an LHC fill. Less annoying to PS Ops. • Increase overall performance by reducing network and MW loads. Completely deterministic. • Good and cheap insurance policy; connect stations as needed at 1000Sf per connection. • Cost for cables and connectors less than 2000 Sf !! • Easier to maintain: I see NO Down Side.