I worked late again last night, only till about 9pm but this time I was triumphant!
My distributed configuration application passed its first major test, grabbing the Front End Electronics configuration information from my central database, parsing it and rebuilding it and then pushing that data to two front end cards.
key: DCS:Detector Configuration System RCU:ReadOut Control Unit
Pre push latency:
2 seconds AFL start (Design constraint, I cant change this.)
0.5 seconds Database query. (This can be increased by a factor of 4 or 5 using prepared statements and 'views')
0.1 seconds Data parsing and rebuilding. (Taking data from the DCS Schema and putting into a useful state)
Push benchmarks
4.8 seconds to Push the 2096 (131 * 8 * 2) registers to the altros. (Via the RCU instruction memory)
8.9 seconds to Push the 2096 and perform 1 to 1 read write checks.
I think these figures can be greatly improved but based on these rough numbers I can estimate the time it will take to perform a whole Time Project Chamber configuration:
Presuming an average partition size of 18 Front End Cards per RCU that makes an altro push time of
4.8 * 9 = 43 seconds.
Due to the limitations of the Front End Cards and the power supply available at the pit the cards have to be stagger started sequentially, waiting 0.6 seconds per card:
0.6 * 18 = 10.8 seconds.
Total: 53.8seconds + unknown DB latency for multiple requests (est 3seconds);
In short, I think that we can confidently commit to having a full TPC configuration in less than 1 minute. The improvements to the RCU firmware should allow building of large instruction memory blocks for multiple register writes, this could improve the performance by a further 20-30% by my estimates.
In short, Woohoo!
Actually, it doesn't - technically.
ReplyDeleteIn the process of finding the faults I've also found a way to double the speed. I just can't make any of it work right now.....