Choose timezone
Your profile timezone:
Developer's meeting
→
Europe/Zurich
present: Milo, Dan, Frank, Roland, Enrico, Andrea, Rene
Hardware accelerated compression (Roland):
- reminder: under non-disclosure agreement with Intel, so results obtained using this hardware are not to be publicised
- but Indico protection should be sufficient
- testing with evaluation card available through OpenLab
- first results (compression time & compression factor), comparison between software & hardware
- Andrea: LHCb usage? Roland: that is more specialised
- Andrea: where does this product stands in Intel's portfolio? Roland: their aim is to integrate everything into the CPU
- Andrea: does this fit in OpenCL? Roland: don't know. Andrea: would be good to keep an eye on OpenCL. Roland: yes, Intel may be interested to know this
- Andrea: how about AccelSD effort from Xilinx? Roland: don't have information
- Frank: is qzip proprietary or open-source? Roland: no reason not to make it open-source; in terms of the compression it anyway implements zlib
- Milo: are there options to implement other schemes than zlib? Roland: they are working on Snappy, lz4
firmware update (Andrea):
- Full-mode generator (Rene, Frans): adding timestamp & CRC
- some errors observed, but not thought to be due to the CRC itself (see below)
- next steps for the generator: mostly expected to be on the s/w side
- Full mode: plans for improved clocking: hiccup: solution using Si5324 chip for precision clocking does not work adequately
- still testing, at the moment
- Enrico: need incrementing timestamp for s/w development. Could this piece of f/w be included in the local emulator? Andrea: need to discuss (would mean a hack of the FELIX code)
- Enrico: alternative could be to modify the timestamp in s/w. Andrea: one more alternative: larger hard-coded pre-loaded number of frames could also help. Enrico: yes, but we'd have to test with several hundred frames only rather than the 10000 that would be "standard"
- Frank: details on the clocking issue? Andrea:
- not sure yet whether Si5324 clocking issue can be solved using a different configuration
- BNL711 board will have the Si5345 on-board so will not suffer from this issue
- HTG710 board was initially anyway "hacked" (some parts replaced with others) because of clocking issues; not a focus of attention because of this, for now
software based compression update (Milo):
- using Eric's reverse-engineered data.
- was jumping between links before, which affected the compression adversely (but slides not yet updated to reflect this having been corrected)
- for now focusing on COLDATA compression; but ~ 20 bytes of header information could be compressed/removed
- implementation of storing differences w.r.t. previous frame can be done without losing compression efficiency
- CRC32: will be really useful only if all of the other data can be reconstructed
- alternative: carry out CRC32 check before compression. Additional time needed for the check could be a concern; need to test
- Dan believes Milo's interpretation of the meaning of error / CRC header words is correct.
- at some point, we need a discussion with the RCE
MW4 planning:
- Enrico: most straightforward approach will be to generate frames internally (option 1 in Andrea's slides) and overwrite timestamp
- benefit: will not need to rely on f/w changes from the side of the FELIX developers' team
There are minutes attached to this event.
Show them.