Warum ist der UDP-Paketempfang während der Ausführung scheinbar optimiert?

Question

Ich führe eine Client-Server-Konfiguration über Ethernet und Messung der Paket-Latenz an beiden Enden. Der Client (Windows) sendet Pakete alle 5 ms (bestätigt mit Drahthai) wie es sollte. Der Server (embedded linux) empfängt jedoch nur Pakete mit Intervallen von 5 ms für einige Sekunden und stoppt dann für 300 ms. Nach dieser Pause beträgt die Latenz nur noch 20 US-Dollar. Nach einer weiteren Pause von etwa ein paar Sekunden dauert es 300 Sekunden. Dies wiederholt sich unbegrenzt (300 ms Pause, 20 us Paketlatenz-Burst). Es scheint, als ob das Serverprogramm mitten in der Ausführung optimiert wird, um IO in kürzeren Bursts zu lesen. Warum passiert dies?

Haftungsausschluss: Ich habe den Code nicht veröffentlicht, da der Client und der Server kleine Teilmengen von komplexeren Anwendungen sind, aber ich bin bereit, es auszumerzen, wenn eine offensichtliche Antwort nicht angezeigt wird.

Answer 1

Ich habe die Messungen auf 1 von 1000 Paketen aufgeteilt und jetzt verhält es sich selbst. Ich benutzte printf alle 5ms, die die printf tx-Warteschlange schließlich vollständig gefüllt haben müssen. Dies verzögerte dann die Ausführung für 300 ms. Sobald printf den Atem angehalten hatte, hatte das Programm eine Warteschlange voller eintreffender Pakete und empfing daher scheinbar alle 20 Sekunden Pakete.

Answer 2

Dies ist UDP, daher gibt es keinen Handshake oder einen Flusskontrollmechanismus. Diese 300 ms müssen wegen der Arbeit sein, die der Server bei der Verarbeitung der empfangenen UDP-Nachrichten macht. Während dieser 300 ms hat der Server ungefähr 60 Nachrichten verloren, die nicht vom Client gelesen wurden.

Sie möchten wahrscheinlich überprüfen, dass der Server nicht mehr als 5 ms bei der Verarbeitung jeder Nachricht benötigt, wenn er einen Thread zur Verarbeitung verwendet. Wenn der Server Multi-Threading zum Verarbeiten der Nachrichten verwendet und die Verarbeitung einige Zeit in Anspruch nimmt, selbst wenn sie 1 ms dauert, befinden Sie sich möglicherweise in einer Situation, in der irgendwann alle Threads um Ressourcen konkurrieren und nicht rechtzeitig abgeschlossen werden lese die nächste Nachricht. Für das Problem, das Sie beschreiben, würde ich wetten, dass der Server Multithread ist und Sie dieses Problem haben. Ich kann das nicht 100% für Mangel an Informationen obwohl versichern. In jedem Fall möchten Sie jedoch die Zeit überprüfen, die zum Verarbeiten von Nachrichten erforderlich ist, da Sie sich möglicherweise mit Echtzeitanforderungen befassen müssen.