2008-11-20 19 views
5

Wenn Sie die Netzwerk-Latenz (time ack received - time msg sent) in einem beliebigen Protokoll über TCP messen, welchen Timer würden Sie dann empfehlen und warum? Welche Auflösung hat es? Was sind weitere Vorteile/Nachteile?Timer zur Messung der Latenz

Optional: Wie funktioniert es?

Optional: Welchen Timer würden Sie NICHT verwenden und warum?

Ich suche hauptsächlich nach Windows/C++ - Lösungen, aber wenn Sie andere Systeme kommentieren möchten, zögern Sie nicht.

(Zur Zeit verwenden wir GetTickCount(), aber es ist nicht eine sehr genaue Timer.)

Antwort

6

Dies ist eine Kopie meiner Antwort aus: C++ Timer function to provide time in nano seconds

Für Linux (und BSD) Sie clock_gettime() verwenden möchten.

#include <sys/time.h> 

int main() 
{ 
    timespec ts; 
    // clock_gettime(CLOCK_MONOTONIC, &ts); // Works on FreeBSD 
    clock_gettime(CLOCK_REALTIME, &ts); // Works on Linux 
} 

Für Fenster möchten Sie die QueryPerformanceCounter verwenden. Und hier ist mehr auf QPC

Offenbar gibt es eine bekannte issue mit QPC auf einigen Chipsätzen, so dass Sie sicherstellen möchten, dass Sie nicht diese Chipsatz haben. Außerdem können einige Dual-Core-AMDs auch eine problem verursachen. Siehe den zweiten Beitrag von sebbbi, wo er sagt:

Queryperformancecounter() und Queryperformance() bietet eine Bit bessere Auflösung, hat aber verschiedene Themen. Zum Beispiel in Windows XP, alle AMD Athlon X2 Dual Core-CPUs kehrt der PC entweder von die Kerne „zufällig“ (der PC manchmal ein bisschen nach hinten springt), es sei denn, Sie speziell AMD Dual-Core-Treiber Paket installieren behebe das Problem. Wir haben nicht festgestellt, andere Dual-Core-CPUs mit ähnlichen Problemen (p4 dual, p4 ht, core2 Dual, core2 Quad, Phenom Quad).

2

Sie erwähnten, dass Sie verwenden GetTickCount(), so werde ich empfehlen, dass Sie einen Blick auf Queryperformancecounter nehmen() .

0

Es gibt wirklich keinen Ersatz für die Anweisung rdtsc. Sie können nicht sicher sein, welche Auflösung der QueryPerformanceCounter unterstützt. Einige haben eine sehr große Granularität (niedrige Inkrementrate/Häufigkeit), manche geben überhaupt nichts zurück.

Stattdessen empfehle ich Ihnen, die Rdtsc-Anweisung zu verwenden. Es erfordert keine Betriebssystemimplementierung und gibt die Anzahl der CPU-internen Taktzyklen zurück, die seit dem Einschalten des Computers/Prozessors/Kerns verstrichen sind. Für einen 3-GHz-Prozessor, der 3 Milliarden Schritte pro Sekunde beträgt - genauer wird es nicht, oder? Diese Anweisung ist für x86-32 und -64 beginnend mit dem Pentium oder Pentium MMX verfügbar. Es sollte daher auch von x86 Linuxes aus zugänglich sein.

Es gibt viele Beiträge darüber auf stackoverflow.com. Ich habe ein paar selbst geschrieben ...

Verwandte Themen