Jak mierzyć opóźnienie w środowiskach o niskim opóźnieniu?

Question

Oto konfiguracja ... Twój system odbiera strumień danych zawierający wiadomości dyskretne (zwykle od 32 do 128 bajtów na wiadomość). W ramach procesu przetwarzania każda wiadomość przechodzi przez dwie osobno oddzielone aplikacje, które wymieniają dane przy użyciu podejścia o małym opóźnieniu (takiego jak przesyłanie wiadomości przez UDP) lub RDMA, a na końcu do klienta za pomocą tego samego mechanizmu.

Zakładając, że możesz wstrzyknąć sobie na dowolnym poziomie, w tym analizę protokołu drutu, jakie narzędzia i/lub techniki użyłbyś do pomiaru opóźnienia systemu. W związku z tym zakładam, że każda wiadomość dostarczona do systemu powoduje, że odpowiedni (choć nie równoważny) komunikat jest przesyłany przez system i dostarczany do klienta.

Jedyne narzędzie, jakie widziałem na tym rynku, to TS-Associates TipOff. Jestem przekonany, że przy odpowiednim dostępie prawdopodobnie mógłbyś zmierzyć te same informacje za pomocą narzędzia do analizy drutu (ala wireshark) i odpowiednich specjalistów, ale czy jest to właściwe podejście, czy też istnieją jakieś rozwiązania dla towarów, z których mogę skorzystać?

Answer 1

Twój ostatni akapit to typowy sposób, w jaki należy to zrobić. Podejrzani w tej dziedzinie (przynajmniej o ile wiem na danych rynkowych (wall street) latencji) są:

• TSA (TS Associates)
• Correlix
• Corvil
• Napatech (sprzęt urządzenia przechwytywania)
• urządzenia Endace (capture hardware)

Znów źle działać firma, która niedawno spalone przez ich VC pieniędzy (4 miliony?).

Dla danych, które są przetwarzane (powiedzmy przy bezpośrednim źródle wymiany lub RMDS lub innym serwerze, który zmienia protokół) na różne formaty, musisz mieć możliwość analizowania ładunków w celu skorelowania wiadomości. Może to być trudne, ponieważ czasami dostawcy danych nie ujawniają definicji komunikatów.

Sądzę, że istnieją urządzenia sprzętowe, które będą wstrzykiwać informacje dotyczące ładunku z sygnaturami czasowymi, tak aby klient mógł je zobaczyć. Oczywiście, jak wskazał kolejny plakat - kwestia czasu jest bardzo ważna. Wszystkie urządzenia i klienci muszą mieć ten sam punkt odniesienia dla czasu. Musi być dokładny ...

Ostatni raz rozmawiałem z TSA, instalacja z 4 punktami obserwacyjnymi była rzędu 150 000 $. Podejrzewam, że pozostałe wymienione powyżej są podobne pod względem ceny.

Wymienione powyżej karty sprzętowe zaczynają się około 2 tys. USD (na kartę z gołą kością) i rosną (znacznie) z tego miejsca.

Aby to zrobić w oprogramowaniu, musisz mieć klientów używających pcap (lub czegoś podobnego) i patrzeć na ładunek i próbować je dopasować. W niektórych przypadkach trudno jest określić to jako deterministyczne - szczególnie na początku "sesji" lub jeśli brakuje wiadomości w jednej rurze. Zwykle po pewnym progu, jeśli coś nie pasuje, po prostu upuszczasz.

EDYTOWANIE: WYŁĄCZENIE ODPOWIEDZIALNOŚCI: Jestem również częścią przedsięwzięcia i powinienem to ujawnić.

Answer 2

Problem z tym związany jest bardzo podobny do pomiaru "prędkości" w przestrzeni: musisz zapytać o opóźnienie w stosunku do czego?Jeśli spróbujesz zmierzyć go na przewodzie, stracisz dodatkowe opóźnienie w przełączaniu lub w stosie protokołów po stronie odbiorczej. Nie da się go zmierzyć od końca do końca, ponieważ komputery będą miały dwa różne zegary, których prawie nie da się pogodzić bez wprowadzenia drobnych błędów (i od siebie od siebie dryfują!)

Jedyne podejście to naprawdę ma jakąś nadzieję na pomiar opóźnienia w obie strony, zakładając, że masz wiadomości, które wracają z jednego końca potwierdzającego pokwitowanie. UDP nie ma ACK w stosie, więc musiałyby być gdzieś zakodowane w aplikacji. To, co robisz, to coś podobnego do x86 z high-resolution timer, aby zmierzyć czas między wysłaniem wiadomości a jej odpowiedzią.

Answer 3

A recent paper może być w pewnym sensie użyteczny (a także znacznie tańszy niż rozwiązania sprzętowe). Istnieją również sposoby dość dokładnego rozliczania skosu zegara; Ostatnim razem, gdy poważnie analizowałem jednokierunkowe pomiary opóźnień (kilka lat temu), najbardziej precyzyjna technika była linear programming algorithm Sue Moon (z kodem odniesienia dogodnie dostępnym here), ale bez użycia niektórych raczej nowoczesnych technik programowania liniowego , jest to dość niepraktyczne zrobić jako algorytm online; najlepiej jest nagrywać sygnatury czasowe bez wykonywania żadnych obliczeń okresowo w ciągu dnia, a następnie uruchomić algorytm LP na zgromadzonych danych. Było kilka innych technik, które były wystarczająco szybkie do zrobienia on-line (w tym seminal paper autorstwa Vern Paxson), ale wszystkie były znacznie mniej dokładne.

Answer 4

Jeśli kilka dodatkowych bajtów na wiadomość nie będzie przesadą dla ciebie, polecam po prostu tasowanie wiadomości u źródła z pełnym znacznikiem czasu (64 bity) i przy każdym dodawaniu do skoku dodawanie/odkładanie znaczników czasu (jeden bajt na znaczek). Analizując przepływ dwukierunkowy, obliczymy skos zegara między polami, a następnie będzie można uzyskać pełne informacje o opóźnieniu w czasie rzeczywistym dla rozważenia lub opublikowania narzędzi monitorowania.