Present: Phil, Giovanna, Roland, Enrico, Filiberto, Milo, Eric, Frank
Primitive finding:
- after the beam run?
- aim: demonstrate that we can keep up hit finding with the data
- can use emulator, but then its ability to send pre-generated data from (another host's) CPU needs to be investigated
- can also send out rate-limited NetIO, can use actual data for this
- or spy on data (cosmics): subscribe to a number of links
- different host, using 10 Gb/s link?
- think about self-triggering PD-SP?
- will need circular buffer
- tentative conclusion: spying on the data (using an additional NetIO subscriber, running on np04-srv-021) seems the most logical choice
Re-ordering:
- discussed w/ Andrea, Enrico yesterday
- issue: where to place this re-ordering module?
- just before/after FIFO driver?
- before: makes conceptual sense since FIFOs care about 32-bit words but not about frames
- drawback: CRC check no longer possible; FIFO driver already interprets header, etc.
- after: FIFO will see existing data
- but some frames split over 2 chunks, need frame analysis to re-construct
- baseline choice: before
- will expand (8+4)-bit data to 16-bit data
- plan: re-order on a per-COLDATA basis
AOB: (Roland:) some compression performance lost due to now running with static Huffman tables?
- should use newest master branch from Intel rather than tarballs etc.
- Milo has also verified that running gzip on the raw fragments leads to a smaller compression factor in the most recent runs
- also, RCE see a similar reduction in compression performance; so conclude that the change must be due to a feature in the data rather than due FELIX specifics
Next meeting tentatively planned for October 31
There are minutes attached to this event.
Show them.