Unitymedia Intel Puma Plattform

[Andreas1969]

Sieht so aus, als wäre der Bug in der FW 6.84 noch nicht behoben worden. :wand:

 

[Menano]

Naja sollte mal noch jemand machen der nicht dauernd 5000er Pings hat.

 

[Andreas1969]

Jedenfalls läuft der VDSL Anschluss klasse :super:

 

[Menano]

Ja ist aber der Anschluss von meiner Freundin. Bei mir gibt es leider nur Unitymedia. :wein:

 

[clitus]

Getestet mit freier FRITZ!Box 6490 mit Firmware v06.84.

1. Test mit Firefox x64 ESR v52.3.0:



2. Test mit Edge v40.15063.0.0:



3. Test mit Vivaldi x64 v1.11.917.43:



Alles drei Tests wurden nacheinander auf demselben PC mit Win10 x64 durchgeführt (jeweils einige Sekunden dazwischen).
Leitungszustand: ohne Last / "idle"
Modemwerte: nach dem Changeday-Desaster wieder i.O.

Scheint also tatsächlich auch auf den verwendeten Browser anzukommen.

 

[Andreas1969]

So, jetzt mal die Auswertung nach 24 Stunden Laufzeit.

FritzBox 6490 Unitymedia



FritzBox 6360 Unitymedia



FritzBox 7490 Telekom



Die 6490 hat da ein richtig dickes Problem.
Die 6360 geht so.
Die 7490 am DSL Anschluß hat perfekte Werte.

 

[Menano]

So sieht es bei mir nach fast 24 Stunden aus:

Fritzbox 6490

Fritzbox 7490 VDSL 100

 

[Edding]

So, jetzt mal die Auswertung nach 24 Stunden Laufzeit.

FritzBox 6490 Unitymedia
649024.PNG


FritzBox 6360 Unitymedia
636024.PNG


FritzBox 7490 Telekom
749024.PNG


Die 6490 hat da ein richtig dickes Problem.
Die 6360 geht so.
Die 7490 am DSL Anschluß hat perfekte Werte.

Das Ergebniss der 6360 ist interessant .. die Kanäle auf der sie sich verbunden hat scheinen gut ausgelastet zu sein .. schön zu sehen an der Latenz die ansteigt und um 21Uhr ihren Peak hat :naughty:

 

[Andreas1969]

Was ist denn da am VDSL Anschluss passiert :kratz:
Gab's da einen mehrstündigen Ausfall?

Oder hast Du in der Box die Funktion "Zwangstrennung durch den Anbieter verschieben" aktiviert und die Box hat ne andere IP bekommen?
Das brauchst Du bei den IP Anschlüssen nicht mehr, da wird nicht mehr alle 24 Stunden zwangsgetrennt. :winken:
Die richtige Einstellung wäre hier "Dauerhaft halten"

 

[Menano]

Nö, das war wohl tatsächlich nen mehrstündiger Totalausfall.

 

[Andreas1969]

Das Ergebniss der 6360 ist interessant .. die Kanäle auf der sie sich verbunden hat scheinen gut ausgelastet zu sein .. schön zu sehen an der Latenz die ansteigt und um 21Uhr ihren Peak hat

Interpretiere ich genau so.
Dann scheint die 6360 den Puma 6 Bug ja nicht zu haben.
In den anderen Zeiträumen sieht das ja ganz passabel aus.

 

[F-orced-customer]

Scheint also tatsächlich auch auf den verwendeten Browser anzukommen.

http://www.dslreports.com/tools/puma6

Sagt denen das mal jemand:
https://www.dslreports.com/forum/r31122204-SB6190-Puma6-TCP-UDP-Network-Latency-Issue-Discussion
:winken:

 

[Andreas1969]

So, wie ich das sehe, ist die FritzBox 6490 schon mal absoluter Schrott :streber:
Die FritzBox 6360 ist schon deutlich besser, aber hat irgendwo auch ein Problem.
Die FritzBox 7490 läuft am DSL Anschluß perfekt.

Unterschreib ich so :kafffee:

Ergebnisse von 6940 neuste FW, 6590, TC7200 und Cisco-Modem wären jetzt noch interessant

Und natürlich die Horizon V1 und V2,
hätten wir fast vergessen :naughty:
Nicht, daß sich nachher herausstellt, daß man mit der Horizon und nachgeschaltetem Router besser fährt

 

[Andreas1969]

Das Ergebniss der 6360 ist interessant .. die Kanäle auf der sie sich verbunden hat scheinen gut ausgelastet zu sein .. schön zu sehen an der Latenz die ansteigt und um 21Uhr ihren Peak hat

Der Graph der letzten 24 Stunden sieht annähernd identisch aus.
Man kann also grundsätzlich sagen, dass die Latenz in der Primetime bei hoher Segmentauslastung ansteigt.
Mich wundert nur, dass beim DSL Anschluss davon überhaupt nichts zu sehen ist. :kratz:

 

[Edding]

Das Ergebniss der 6360 ist interessant .. die Kanäle auf der sie sich verbunden hat scheinen gut ausgelastet zu sein .. schön zu sehen an der Latenz die ansteigt und um 21Uhr ihren Peak hat

Der Graph der letzten 24 Stunden sieht annähernd identisch aus.
Man kann also grundsätzlich sagen, dass die Latenz in der Primetime bei hoher Segmentauslastung ansteigt.
Mich wundert nur, dass beim DSL Anschluss davon überhaupt nichts zu sehen ist. :kratz:

Der DSL-Anschluss wir keine Überlastung zur Prime-Time haben :super:

 

[Menano]

Mit dem neuen Kabel läuft der Rückkanal etwas stabiler. Ich denke fast die 6.84 hat keine Probleme mehr. Die Pingspikes kommen einfach von meinem Anschluss.

Und der VDSL Anschluss ist fast nur down.

 

[why_]

Ihr könnt DSL und Kabel bei so einem Test nicht vergleichen. Bei DSL kann das Modem labern wie es lustig ist, bei Kabel bekommen die Modems timeslots, solange ihr also nicht alleine in eurem Segment seit werdet ihr immer Ausschläge haben. Nebenbei hat GPON das selbe Problem. PTP ist hier eigentlich der Königsweg, leider gehen den nur Stadtwerke und die Telekom baut sich da wieder Billig schrott der denen in Zukunft auf die Füße fällt.

 

[Menano]

Ausschläge bis 100 oder 200ms wären ja verkraftbar. Aber nicht bis 3000ms+ :hammer:

 

[MichaelBre]

Bei DSL kann das Modem labern wie es lustig ist, bei Kabel bekommen die Modems timeslots, solange ihr also nicht alleine in eurem Segment seit werdet ihr immer Ausschläge haben.

Spannende Aussage.
Und wie erklärst du dir dann meine Werte?

Es ist kein UM Gerät, eine FritzBox oder ein Hitron...

 

[Andreas1969]

Es ist kein UM Gerät, eine FritzBox oder ein Hitron...

Es ist ein Gerät, welches nicht den Puma 6 verbaut hat.

 

[F-orced-customer]

Ihr sollt Eure Modems testen, nicht das DOCSIS-Netzwerk:

http://badmodems.com/Tools.htm

Some chip makers have hidden issues from the ping command.

Ping CANNOT be used reliably to test for latency or jitter. The tests below use TCP

http://badmodems.com/Forum/viewtopic.php?p=46#p46

The Puma test at DSLR does not always pick the best closest server to you for what ever reason.. If you go to the speed test page and then to settings..
56 Amsterdam, Netherlands, EU (softlayer) +IPv6
76 Darmstadt, Germany, EU (nynex.de) +IPv6
4 Dublin, Ireland, EU (amazon)
26 Frankfurt, DE, EU (INTERNAP)
44 Frankfurt, DE, EU (amazon)
46 London, UK (linode) +IPv6
9 St. Ghislain, Belgium, EU (google)
78 Zurich, Switzerland, EU (iWay.ch) +IPv6

http://www.dslreports.com/tools/puma6 , am besten mit Chrome, und einfach den Text kopieren, Screenshots sind überflüssig und umständlich.

 

[why_]

Bei DSL kann das Modem labern wie es lustig ist, bei Kabel bekommen die Modems timeslots, solange ihr also nicht alleine in eurem Segment seit werdet ihr immer Ausschläge haben.

Spannende Aussage.
Und wie erklärst du dir dann meine Werte?

Es ist kein UM Gerät, eine FritzBox oder ein Hitron...

Der Graph bestätigt doch wunderbar was ich geschrieben habe. :kratz:
Erkläre doch mal kurz was der Graph an meiner aussage wiederlegt?

 

[F-orced-customer]

:traurig: :winken:

Ping CANNOT be used reliably to test for latency or jitter. The tests below use TCP

 

[nts]

Ihr sollt Eure Modems testen, nicht das DOCSIS-Netzwerk:

http://badmodems.com/Tools.htm

Vielleicht am besten gleich mit PingPlotter wie dort beschrieben (TCP statt ICMP), der Brower-Test scheint ja recht inkonsistent zu sein.

 

[F-orced-customer]

Vielleicht am besten gleich mit PingPlotter wie dort beschrieben (TCP statt ICMP), der Brower-Test scheint ja recht inkonsistent zu sein.

man qperf. Aber ich finde dafür keine server.

- Jitter (latency variation): can be measured with an Iperf UDP test.

https://iperf.fr/iperf-servers.php

$ iperf3 -c ping.online.net -u --get-server-output
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 18.251 ms 0/159 (0%)
[ 4] Sent 159 datagrams

Server output:
Time: Sun, 17 Sep 2017 19:58:24 GMT
Accepted connection from 109.193.xxx.xxx, port 44360
Cookie: tom3.1505678304.724190.060c44ab4c33d
[ 13] local 62.210.18.40 port 5201 connected to 109.193.xxx.xxx port 44545
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 13] 0.00-2.00 sec 248 KBytes 1.02 Mbits/sec 18.721 ms 0/31 (0%)
[ 13] 2.00-4.00 sec 256 KBytes 1.05 Mbits/sec 18.115 ms 0/32 (0%)
[ 13] 4.00-6.00 sec 256 KBytes 1.05 Mbits/sec 17.551 ms 0/32 (0%)
[ 13] 6.00-8.00 sec 256 KBytes 1.05 Mbits/sec 18.485 ms 0/32 (0%)
[ 13] 8.00-10.00 sec 256 KBytes 1.05 Mbits/sec 18.251 ms 0/32 (0%)
[ 13] 10.00-10.04 sec 0.00 Bytes 0.00 bits/sec 18.251 ms 0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 13] 0.00-10.04 sec 0.00 Bytes 0.00 bits/sec 18.251 ms 0/159 (0%)
CPU Utilization: local/receiver 0.0% (0.0%u/0.0%s), remote/sender 0.6% (0.4%u/0.2%s)


iperf Done.

:kratz:

$ iperf3 -c ping.online.net -u -t 60 --get-server-output -P 4

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-60.00 sec 7.50 MBytes 1.05 Mbits/sec 49.535 ms 357/959 (37%)
[ 4] Sent 959 datagrams
[ 6] 0.00-60.00 sec 7.50 MBytes 1.05 Mbits/sec 50.028 ms 419/958 (44%)
[ 6] Sent 958 datagrams
[ 8] 0.00-60.00 sec 7.50 MBytes 1.05 Mbits/sec 58.321 ms 822/958 (86%)
[ 8] Sent 958 datagrams
[ 10] 0.00-60.00 sec 7.50 MBytes 1.05 Mbits/sec 16.644 ms 437/958 (46%)
[ 10] Sent 958 datagrams
[SUM] 0.00-60.00 sec 30.0 MBytes 4.19 Mbits/sec 43.632 ms 2035/3833 (53%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 13] 0.00-60.50 sec 0.00 Bytes 0.00 bits/sec 49.535 ms 357/959 (37%)
[ 17] 0.00-60.50 sec 0.00 Bytes 0.00 bits/sec 50.028 ms 419/958 (44%)
[ 25] 0.00-60.50 sec 0.00 Bytes 0.00 bits/sec 58.321 ms 822/958 (86%)
[ 33] 0.00-60.50 sec 0.00 Bytes 0.00 bits/sec 16.644 ms 437/958 (46%)
[SUM] 0.00-60.50 sec 0.00 Bytes 0.00 bits/sec 43.632 ms 2035/3833 (53%)
CPU Utilization: local/receiver 0.1% (0.0%u/0.1%s), remote/sender 0.9% (0.0%u/0.9%s)


iperf Done.

$ iperf3 -c ping.online.net -u --get-server-output -P 10
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 80.041 ms 65/160 (41%)
[ 4] Sent 160 datagrams
[ 6] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 46.076 ms 114/160 (71%)
[ 6] Sent 160 datagrams
[ 8] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 36.555 ms 153/159 (96%)
[ 8] Sent 159 datagrams
[ 10] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 29.453 ms 155/159 (97%)
[ 10] Sent 159 datagrams
[ 12] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 23.362 ms 156/159 (98%)
[ 12] Sent 159 datagrams
[ 14] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 24.421 ms 156/159 (98%)
[ 14] Sent 159 datagrams
[ 16] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 25.510 ms 156/159 (98%)
[ 16] Sent 159 datagrams
[ 18] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 27.604 ms 156/159 (98%)
[ 18] Sent 159 datagrams
[ 20] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 45.870 ms 154/159 (97%)
[ 20] Sent 159 datagrams
[ 22] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 29.650 ms 65/159 (41%)
[ 22] Sent 159 datagrams
[SUM] 0.00-10.00 sec 12.5 MBytes 10.5 Mbits/sec 36.854 ms 1330/1592 (84%)

^= http://www.dslreports.com/tools/puma6

$ iperf3 -c ping.online.net -u -P 10 -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 9.528 ms 1/161 (0.62%)
[ 4] Sent 161 datagrams
[ 6] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 9.590 ms 2/161 (1.2%)
[ 6] Sent 161 datagrams
[ 8] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 8.222 ms 1/161 (0.62%)
[ 8] Sent 161 datagrams
[ 10] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 8.740 ms 2/161 (1.2%)
[ 10] Sent 161 datagrams
[ 12] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 8.883 ms 1/161 (0.62%)
[ 12] Sent 161 datagrams
[ 14] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 9.072 ms 1/161 (0.62%)
[ 14] Sent 161 datagrams
[ 16] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 9.306 ms 1/161 (0.62%)
[ 16] Sent 161 datagrams
[ 18] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 9.548 ms 2/161 (1.2%)
[ 18] Sent 161 datagrams
[ 20] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 9.969 ms 2/161 (1.2%)
[ 20] Sent 161 datagrams
[ 22] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec 10.811 ms 2/161 (1.2%)
[ 22] Sent 161 datagrams
[SUM] 0.00-10.00 sec 12.6 MBytes 10.6 Mbits/sec 9.367 ms 15/1610 (0.93%)

iperf Done.