1 / 11

Data Queue

Aim: collect (reassembling from the “UDP puzzle”) data reading from the WR network and redistribute them to the proper DAQ elements. Data Queue. KM3NeT Phase 1 throughput. 26 DUs 18 DOMs per DU 31 3'' PMTs per DOM

matteo
Télécharger la présentation

Data Queue

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Aim: collect (reassembling from the “UDP puzzle”) data reading from the WR network and redistribute them to the proper DAQ elements Data Queue

  2. KM3NeT Phase 1 throughput • 26 DUs • 18 DOMs per DU • 31 3'' PMTs per DOM • considering dominant the optical data flow and acoustic ~½ optical. Slow-control contribution is considered negligible. • 6 Bytes per hit • two scenarios: the realistic and the conservative

  3. KM3NeT Phase 1 throughput - 2 Presence of the 40K and the DOM threshold set to 0.3 p.e. Acoustic data throghput supposed to be ~ 1.5 Gbps

  4. DQ Buffering Number of STS Fit the number of required DQs with the maximum buffering needed, due to possible network delays, and with the available RAM. Seconds of acquisition

  5. Optical data sender thread Acoustic data sender thread Input thread Shared memory Other instruments data sender thread Control thread (CHSM interface) Data Queue threads scheme To Data Filters Data from multiple DOMs To DB Writer

  6. Input: the “UDP puzzle” The UDP packet (datagram) can be at most the MTU = 1500B < sizeof(frame) • A frame is splitted into several datagrams By the intrinsic nature of the UDP protocol we have that: • A datagram can be lost • Two consecutive datagrams can arrive in inverted order

  7. Proposed solution • Use a kind o “cinise boxes” with expiration

  8. DQ data sender / Optical data • Route the collected STS to a different DF each time

  9. DQ data sender / Other type of data • Acoustic data in a continuous stream, addressing a specific subset of sensors to a specific DF • Instrument data and slow-control to the DB Writer through ControlHost

  10. Toy code • Small program initially developed to test the “reliability” of the UDP link • Can read from a UDP socket, implement some kind of analysis and send the result to a ControlHost server • Tested on local network using Vis (see the wiki) https://dl.dropboxusercontent.com/u/257676636/CLB_out_test.tar.gz

More Related