Come misurare la latenza negli ambienti a bassa latenza?

Question

Ecco l'installazione ... Il sistema riceve un flusso di dati che contiene messaggi discreti (in genere tra 32-128 byte per messaggio). Come parte della tua pipeline di elaborazione, ogni messaggio passa attraverso due applicazioni fisicamente separate che scambiano i dati utilizzando un approccio a bassa latenza (come messaggistica su UDP) o RDMA e infine a un client tramite lo stesso meccanismo.

Supponendo che si possa iniettarsi a qualsiasi livello, compresa l'analisi del protocollo del filo, quali strumenti e/o tecniche si utilizzeranno per misurare la latenza del sistema. Come parte di questo, presumo che ogni messaggio che viene consegnato al sistema porti a un messaggio corrispondente (sebbene non equivalente) che viene spinto attraverso il sistema e consegnato al client.

L'unico strumento che ho visto sul mercato come questo è TS-Associates TipOff. Sono sicuro che con il giusto accesso potresti probabilmente misurare le stesse informazioni usando uno strumento di analisi dei fili (ala wireshark) e i dissettori giusti, ma è questo l'approccio giusto o ci sono soluzioni per le materie prime che posso usare?

Answer 1

L'ultimo paragrafo è il modo tipico in cui deve essere eseguito. I soliti noti in questo campo (almeno per quanto ne so per dati di mercato (Wall Street) latenza) sono:

• TSA (TS Associates)
• Correlix
• Corvil
• Napatech (hardware dispositivi di acquisizione)
• dispositivi Endace (cattura hardware)

C'era un'altra società mal gestito che recentemente ha bruciato attraverso la loro VC soldi (4 milioni?).

Per i dati elaborati (diciamo in un feed di scambio diretto o RMDS o altro server che modifica il protocollo) in diversi formati, è necessario essere in grado di analizzare i payload per correlare i messaggi. Può essere difficile perché a volte i fornitori di dati non espongono le definizioni dei messaggi.

Penso che ci siano dispositivi hardware che inietteranno informazioni di payload con data e ora in modo che il client possa vederle. Naturalmente, come ha sottolineato un altro manifesto, la questione del tempo è molto importante. Tutti i dispositivi e i client devono avere lo stesso punto di riferimento per volta. Deve essere accurato ...

L'ultima volta che ho parlato con TSA, un'installazione con 4 punti di osservazione era dell'ordine di $ 150k. Sospetto che gli altri elencati sopra abbiano un prezzo simile.

Le schede hardware elencate sopra iniziano a circa $ 2k (per una scheda bare bare) e salgono (significativamente) da lì.

Per farlo nel software è necessario disporre di client che utilizzano pcap (o qualcosa di simile) e guardare i payload e cercare di abbinarli. In alcuni casi è difficile ottenere che questo sia deterministico, specialmente all'inizio di una "sessione" o se mancano messaggi da una pipe. Di solito, dopo una certa soglia, se non si combina qualcosa, basta lasciarlo cadere.

MODIFICA: DISCLAIMER: Sono anch'io parte dell'avventura ora e devo rivelarlo.

Answer 2

Il problema con questo è lo stesso che misurare la "velocità" nello spazio: devi chiedere la latenza relativa a cosa?Se provi a misurarlo sul cavo, perderai ogni latenza aggiuntiva nella commutazione o nello stack del protocollo sul lato ricevente. Non si può realmente misurarlo end-to-end, poiché i computer avranno due orologi diversi che è quasi impossibile conciliare senza introdurre piccoli errori (e si allontanano l'uno dall'altro!)

L'unico approccio che ha davvero qualche speranza sta misurando la latenza di andata e ritorno, assumendo che tu abbia messaggi che tornano da un capo che conferma ricevuta. UDP non ha ACK nello stack, quindi dovrebbero essere codificati nell'applicazione da qualche parte. Quello che fai è usare qualcosa come il high-resolution timer dell'x86 per misurare l'intervallo di tempo tra un messaggio inviato e la sua risposta.

Answer 3

A recent paper potrebbe essere di qualche utilità (e sarebbe anche molto più economico rispetto alle soluzioni basate su hardware). Ci sono anche modi per spiegare in modo abbastanza accurato l'inclinazione dell'orologio; l'ultima volta che ho esaminato seriamente la ricerca di misurazione della latenza a una via (un paio di anni fa), la più accurata tecnica era una linear programming algorithm di Sue Moon (con codice di riferimento convenientemente disponibile here), ma senza utilizzare alcune tecniche di programmazione lineare piuttosto moderne , è abbastanza poco pratico fare come un algoritmo online; è meglio registrare solo i timestamp senza eseguire calcoli periodici durante il giorno, quindi eseguire l'algoritmo LP sui dati accumulati in seguito. C'erano alcune altre tecniche abbastanza veloci da essere eseguite online (incluso lo seminal paper di Vern Paxson), ma erano tutte molto meno accurate.

Answer 4

Se molti più byte per messaggio non saranno eccessivi, raccomanderei semplicemente di timbrare il messaggio all'origine con timestamp completo (64 bit) e su ogni hop aggiungere la voce/lasciare i timestamp deltas (un byte per francobollo). Analizzando un flusso bidirezionale, si capirà l'inclinazione dell'orologio tra i riquadri e quindi sarà possibile disporre di informazioni complete sulla latenza in tempo reale per la propria considerazione o per la pubblicazione sugli strumenti di monitoraggio.