1 / 13

“ PC  PC Latency measurements ”

“ PC  PC Latency measurements ”. G.Lamanna , R.Fantechi & J.Kroon (CERN) TDAQ WG – 8.9.2011. Introduction. Why the latency measurement is important for us?:

huy
Télécharger la présentation

“ PC  PC Latency measurements ”

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. “PCPCLatencymeasurements” G.Lamanna, R.Fantechi & J.Kroon (CERN) TDAQ WG – 8.9.2011

  2. Introduction • Why the latency measurement is important for us?: • Primitives transmission to the L0TP through ethernet (Low level protocol, possibility to have switches, small spread in latency…) • Data collection in L1 PCs. (which protocol? Routers? Network congestions? Reliability? Fast check at application levels?...) • L1 trigger distribution. (Small latency? Latency stability? Broadcasting? …) • Feedback to select computer and network HW • Select the transmission protocol

  3. Transmission protocol: UDP vs TCP? • TCP • GOOD: • provides reliable, ordereddelivery of a • stream of bytes. • Flowcontrol. • BAD: • heavyprotocol to be implemented in hardware, • each packet needs to be acknowledged and at high rate can become a problem. • The latency is intrinsically not stable. • The packets can be fractioned for transmission optimization reasons • UDP • GOOD: • simpleand fastprotocol, • easyto be implemented in hardware, • does not require big resources. • BAD: • no reliability, ordering, or data integrity • provides an unreliableservice and datagrams may arrive out of order.

  4. Test setup • The software tools for measure the latency provide averages and isn’t clear the contribution to the latency due to the sender and the receiver • HW approach: use the oscilloscope to measure the time difference in packet transmission PC #1 PC #2 ETH LPT LPT scope [see also R.Fantechi TDAQ 25.5.2011]

  5. Hardware used LKRPN0 PCATE GPU1

  6. Results: PCATE & GPU1 PCATE PCATE GPU1 GPU1

  7. Results: GPU1 & LKRPN0 LKRPN0 LKRPN0 GPU1 GPU1

  8. Results: LKRPN0 & PCATE LKRPN0 LKRPN0 PCATE PCATE

  9. Cross check with sockperf • In GPU1->PCATE the result is compatible with the HW measurements • In the PCATE->GPU1 we have a very big latency PCATE PCATE GPU1 GPU1

  10. GPU1 mother board architecture Processor 1 Processor 2 QPI QPI QPI Test 2 PCI-E x4 QUAD PORT GBE IOH IOH QPI Test 1 ESIx4 PCI-E x1 DUAL PORT GBE ICH10R

  11. “Schizophrenic” test Same PC, different NIC Same PC, Same NIC, different port GPU1 GPU1 GPU1 GPU1

  12. What we learned from this first studies? • Both the characteristics of the sender and the receiver are important for the latency • In particular the sender seems to play an important role using sockperf • The latency increases with the packet dimension • The frequency of the packet isn’t relevant until the “jump” • The “jump” happens at relatively high frequency rate (> 20 kHz) • The “jump” probably depends on the NIC/BUS/Chipset more than on CPU/Memory • The absolute value of the latency depends on the PCs setup and the packet dimension: • Minimum (~300 B packets): ~50 us (recvGPU1 or LKRPN0), ~60 us (recv PCATE) • Maximum (~1500B, no jumps if delay is >50us): ~70 us (recvGPU1 or LKRPN0), ~90 us (recvPCATE)

  13. To Do • Use the TALK board to go “faster” (the 10 MHz can’t be reached using PCs) • Identify the responsible of the “jumps”: • Same NIC on different PCs • Different NICs on same PC • Measure the latency with the TELL1 • Any suggestions is more than welcome!!! LKRPN0 PCATE GPU1

More Related