Erfahrungen mit Kabeldeutschland 1Gigabit

[DarkStar]

Gerade mal am großen Ryzen Rechner getestet und wie zu erwarten keine Probleme.

Puma7.jpg

[sch4kal]

Gerade mal am großen Ryzen Rechner getestet und wie zu erwarten keine Probleme.

Puma7.jpg

Rechner ist pupsegal, ich hab das mit einem 7 Jahre alten Thinkpad getestet.

[DarkStar]

Rechner ist nicht Egal-
Kleinere CPU = Generell höhere Grundlast und genau sowas beeinflusst solche Tests, die über den Browser gehen.

[sch4kal]

Rechner ist nicht Egal-
Kleinere CPU = Generell höhere Grundlast und genau sowas beeinflusst solche Tests, die über den Browser gehen.

Jeder halbwegs moderne PC der letzten 7-8 Jahre kommt damit problemlos zurecht.
Wichtig ist nur, das die Leitung nicht durch andere Downloads etc. belastet wird.

[robert_s]

Es misst die Latenz von sehr vielen, kleinen TCP-Requests.

Stimmt gar nicht. Der Test ist nicht richtig dokumentiert. Tatsächlich schickt er nicht nur TCP-Requests, sondern baut TCP-Verbindungen auf und schickt HTTP-Requests darüber:

Code: Alles auswählen

xhr.open("GET", hsp+"://t"+host+".dslreports.com/front/0k?"+Math.random());

Gemessen wird, wie lange es dauert, bis die HTTP-Antwort 200 kommt. Also TCP-Verbindungsaufbau + HTTP-Request schicken + Antwort erhalten. Insgesamt gehen (nach dem DNS-Lookup) 10 IP-Pakete pro "Messung" über die Leitung.

Dadurch sind auch die Latenzen auch so hoch. Ich habe eine Round-Trip-Time von ca. 20ms zum Server t26. Bei einer Messung war der TCP-Request zum Verbindungsaufbau nach 19ms beantwortet, dann wurde der http-Request geschickt, der nach 26ms quittiert wurde, und nach 29ms kam die http-Antwort. Genau dauerte es 48,11ms - als niedrigsten Messwert zeigt der Test dann 49ms an. Also mehr als das doppelte der tatsächlichen Round Trip Time zum Testserver.

Übrigens führt der Test die Zeitmessung mittels performance.now() durch, wozu die Dokumentation sagt:

https://developer.mozilla.org/en-US/doc ... rmance/now

The timestamp is not actually high-resolution. To mitigate security threats such as Spectre, browsers currently round the results to varying degrees. (Firefox started rounding to 1 millisecond in Firefox 60.) Some browsers may also slightly randomize the timestamp.

Mit Firefox 65.0.1 habe ich mal einen Breakpoint an der Stelle gesetzt, wo der Test Messwerte >100ms behandelt. Er hat 187ms ermittelt. Wireshark zeigt mir aber, dass zuletzt zwei Requests durcheinander liefen (die ersten TCP-SYN Pakete wurden direkt nacheinander versendet). Der erste Request war nach 50ms beantwortet, der zweite nach 61ms. 187ms hat da gar nichts gedauert.

Der Test scheint unzuverlässig zu sein und selbst Ping-Spikes zu "produzieren".

[sch4kal]

Insgesamt gehen (nach dem DNS-Lookup) 10 IP-Pakete pro "Messung" über die Leitung.

Messung == Samples ?
Meine Messungen ergeben 20 HTTP-Requests/Responses pro Sekunde.
TCP sind es etwa ~105/s.

Dadurch sind auch die Latenzen auch so hoch. Ich habe eine Round-Trip-Time von ca. 20ms zum Server t26. Bei einer Messung war der TCP-Request zum Verbindungsaufbau nach 19ms beantwortet, dann wurde der http-Request geschickt, der nach 26ms quittiert wurde, und nach 29ms kam die http-Antwort. Genau dauerte es 48,11ms - als niedrigsten Messwert zeigt der Test dann 49ms an. Also mehr als das doppelte der tatsächlichen Round Trip Time zum Testserver.

Ist auch irrelevant, solange alle denselben Test nutzen. Misst du deine RTT über ICMP oder aus Wireshark ?

Übrigens führt der Test die Zeitmessung mittels performance.now() durch, wozu die Dokumentation sagt:

https://developer.mozilla.org/en-US/doc ... rmance/now

The timestamp is not actually high-resolution. To mitigate security threats such as Spectre, browsers currently round the results to varying degrees. (Firefox started rounding to 1 millisecond in Firefox 60.) Some browsers may also slightly randomize the timestamp.

Auf die Millisekunde hin oder her kommt es nicht an.

Mit Firefox 65.0.1 habe ich mal einen Breakpoint an der Stelle gesetzt, wo der Test Messwerte >100ms behandelt. Er hat 187ms ermittelt. Wireshark zeigt mir aber, dass zuletzt zwei Requests durcheinander liefen (die ersten TCP-SYN Pakete wurden direkt nacheinander versendet). Der erste Request war nach 50ms beantwortet, der zweite nach 61ms. 187ms hat da gar nichts gedauert.

Der Test scheint unzuverlässig zu sein und selbst Ping-Spikes zu "produzieren".

Hast du das schon dem Schöpfer dieses Tests gezeigt ?
Ich bekomme keine Pingspikes mit dem TC4400, selbst wenn ich 10 Tests hintereinander mache keinen Einzigen.

[robert_s]

Der Test scheint unzuverlässig zu sein und selbst Ping-Spikes zu "produzieren".

Hast du das schon dem Schöpfer dieses Tests gezeigt ?
Ich bekomme keine Pingspikes mit dem TC4400, selbst wenn ich 10 Tests hintereinander mache keinen Einzigen.

Du testest nicht nur das TC4400, sondern u.a. auch Deinen Browser. Welchen verwendest Du?

[sch4kal]

Unter Win: Chrome 72.0.3626.119
Unter Linux: Firefox 63.0.3

[robert_s]

Unter Win: Chrome 72.0.3626.119
Unter Linux: Firefox 63.0.3

Ich habe jetzt mal in meinem Ubuntu 16.04 den direkten Vergleich gemacht zwischen Firefox 65.0.1 und dem Chromium-Browser 71.0.3578.98, und mal gleichzeitig in beiden Browsern den puma6-Test gestartet. Das Ergebnis war einiges Rot im Firefox, während im Chromium alles grün blieb. Das war in mehreren Versuchen so. In Chromium sind durchweg Latenzen und Jitter niedriger.

Fazit: Firefox 65.0.1 ist eher ungeeignet für den Test.

[sch4kal]

Unter Win: Chrome 72.0.3626.119
Unter Linux: Firefox 63.0.3

Ich habe jetzt mal in meinem Ubuntu 16.04 den direkten Vergleich gemacht zwischen Firefox 65.0.1 und dem Chromium-Browser 71.0.3578.98, und mal gleichzeitig in beiden Browsern den puma6-Test gestartet. Das Ergebnis war einiges Rot im Firefox, während im Chromium alles grün blieb. Das war in mehreren Versuchen so. In Chromium sind durchweg Latenzen und Jitter niedriger.

Fazit: Firefox 65.0.1 ist eher ungeeignet für den Test.

puma6-test-ff.PNG

Gerade unter FF 65.0.2 gemacht.