markuseicher Ich habe mir die CNLAB Analyse einmal angechaut und unsere KI um Rat gefragt. Hier sind die Antworten der zwei Messungen. Hast du die beiden CNLAB Tests mit WIFI gemacht? Falls du mir noch deine Kundennummer zusenden könntest via Privatnachricht, kann ich die Leitung einmal ausmessen.
📦 Datenverkehr und Paketstatistik
Data packets (sent by server): 496′876
→ Anzahl der vom Server gesendeten Datenpakete.
ACK packets (received at server side): 27′584
→ Anzahl der Bestätigungspakete (ACKs), die der Server vom Client erhalten hat. Diese bestätigen den Empfang von Datenpaketen.
Data packets / ACK packets ratio: 18.0
→ Durchschnittlich wurden 18 Datenpakete pro ACK gesendet. Ein hoher Wert kann auf eine effiziente Verbindung hindeuten.
—
🔁 Verluste und Wiederholungen
Bytes retransmitted (sent by server): 83′220 Bytes (Packetloss: 0.0 ‰)
→ Menge der erneut gesendeten Daten aufgrund von Paketverlusten. Die Verlustquote ist extrem niedrig (0.0 Promille), was sehr gut ist.
DupAcksIn (received at server side): 11′223
→ Anzahl der doppelten ACKs, die der Server erhalten hat. Diese können auf verlorene Pakete oder Netzwerkprobleme hindeuten.
—
📐 Empfangsfenster (Client-seitig)
MinRwinRcvd: 0
→ Das minimale Empfangsfenster des Clients war 0, was bedeutet, dass der Client zeitweise keine Daten empfangen konnte (vielleicht überlastet).
MaxRwinRcvd: 4′194′048
→ Maximale Größe des Empfangsfensters – das ist sehr groß und zeigt, dass der Client grundsätzlich große Datenmengen verarbeiten kann.
—
⏱️ Sende-Limitierungen
Diese Werte zeigen, warum der Server das Senden von Daten zeitweise einschränken musste:
SndLimTimeRwin: 0 ms (Limited client side: 3 %)
→ Der Server war für 0 ms durch das Empfangsfenster des Clients limitiert (also fast nie). Nur 3 % der Zeit war der Client der limitierende Faktor.
SndLimTimeCwnd: 13 ms (Congestion Limited: 88 %)
→ Der Server war für 13 ms durch Netzwerküberlastung limitiert. Das ist der Hauptgrund für Sendeeinschränkungen (88 %).
SndLimTimeSender: 1 ms (Limited server side: 9 %)
→ Der Server selbst war für 1 ms limitiert, z. B. durch CPU oder andere Ressourcen.
Auch diese zweite Messung zeigt eine insgesamt stabile TCP-Verbindung, aber mit leicht anderen Charakteristika. Schauen wir uns SndLimTimeCwnd und die anderen Limiter im Detail an:
—
📊 SndLimTimeCwnd: 7 ms (Congestion Limited: 75 %)
Der Server war 7 Millisekunden lang durch das Congestion Window limitiert.
Das entspricht 75 % der gesamten Sendezeit, in der der Server Daten hätte senden können.
Das bedeutet: Auch hier war die Netzwerküberlastung der Hauptgrund, warum der Server nicht durchgehend senden konnte.
Im Vergleich zur vorherigen Messung (13 ms, 88 %) ist die absolute Zeit kürzer, aber der relative Anteil bleibt hoch. Das zeigt, dass die Verbindung auch hier vorsichtig agieren musste, um Überlastung zu vermeiden.
—
🔁 Weitere Limiter im Vergleich
ParameterWertBedeutungSndLimTimeRwin1 ms (12 %)Der Client war etwas häufiger der limitierende Faktor als zuvor (12 % statt 3 %).SndLimTimeSender1 ms (13 %)Der Server selbst war ebenfalls leicht häufiger limitiert (13 % statt 9 %).
→ Insgesamt ist die Last etwas gleichmäßiger verteilt als bei der ersten Messung, aber Congestion bleibt der dominante Faktor.
—
📌 Fazit
Die Verbindung war effizient, aber auch hier war die Netzwerküberlastung der Hauptgrund für Sendeeinschränkungen.
Der Client war etwas häufiger überlastet (MinRwinRcvd = 0, SndLimTimeRwin = 12 %), was auf temporäre Engpässe hindeutet.
Die Paketverlustrate bleibt extrem niedrig (0.0 ‰), was sehr positiv ist.
Liebe Grüsse
Daniele
