Unitymedia Intel Puma Plattform

[F-orced-customer]

Ah doch:
https://www.unitymediaforum.de/viewtopic.php?p=382714#p382714

 

[Conan179]

Nein echt?

Ich behaupte sogar mal das AVM keinen Helm darum gemacht hat und es in die Info.txt rein geschrieben hat und zwar als erstes:
"Aktueller Modemtreiber implementiert"
In der Anklage gegen arris steht das 8ntel schon einen software Patch raus gebracht hat, nur arris hat ihn nicht ausgeliefert. Wurde Sinn ergeben.

und wow das hab ich schon vor 10tagen geschrieben!

 

[F-orced-customer]

Was kann ich dafür, dass AVM changelogs info.txt nennt, das findet google unter changelog nicht :kratz:

 

[Conan179]

Oh fein! jetzt werden Legastheniker auch noch von ihnen beleidigt. Machen sie so ruhig weiter.

 

[F-orced-customer]

Wozu denn streiten, freuen wir uns doch dass es einen Fix geben könnte und hoffen auf baldiges update der Connect Box u.a. :smile:

 

[MichaelBre]

Sorry, Beiträge ohne Rechtschreibung kann man schonmal überlesen :kafffee:

Komm mal von deinem hohen Ross herunter...
Ist ja furchtbar mit dir.

 

[F-orced-customer]

Schon korrigiert :smile:

 

[F-orced-customer]

Was ist denn das für 1 Mist, mein pingplot ist weg :traurig:

https://www.thinkbroadband.com/broadband/monitoring/quality/share/a5bf281a6d9805ad63d9f9e9fad95d8888021ce7-22-09-2017

 

[Andreas1969]

Was ist denn das für 1 Mist, mein pingplot ist weg :traurig:

https://www.thinkbroadband.com/broadband/monitoring/quality/share/a5bf281a6d9805ad63d9f9e9fad95d8888021ce7-22-09-2017

Hat sich wohl Deine IP geändert

 

[F-orced-customer]

No war ja disabled snapshot vom 22.

Oh iperf3 -u hat nen bug wenn der server ausgelastet ist, jitter = 0, transfer,bandwidth != 0

<i>
</i>$ iperf3 -c ping.online.net -p 5209 -u --get-server-output
Connecting to host ping.online.net, port 5209
[ 4] local 192.168.0.105 port 39412 connected to 62.210.18.40 port 5209
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 16
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/0 (0%)
[ 4] Sent 0 datagrams
Server output:
Time: Mon, 25 Sep 2017 17:07:23 GMT
Accepted connection from xxx, port 43911 Cookie: tom3.1506359242.441210.07e311606f385
[ 6] local 62.210.18.40 port 5209 connected to xxx port 39412
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 6] 0.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 6] 2.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 6] 4.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 6] 6.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 6] 8.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
[ 6] 10.00-10.03 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 6] 0.00-10.03 sec 0.00 Bytes 0.00 bits/sec 0.000 ms 0/0 (0%)
CPU Utilization: local/receiver 0.0% (0.0%u/0.0%s), remote/sender 0.2% (0.1%u/0.1%s)
iperf Done.
$ iperf3 -c bouygues.iperf.fr -4 -p 5209 -u
Connecting to host bouygues.iperf.fr, port 5209
[ 4] local 192.168.0.105 port 35452 connected to 194.158.119.190 port 5209
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 16
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 19.616 ms 1/159 (0.63%)
[ 4] Sent 159 datagrams
iperf Done.

 

[F-orced-customer]

Webseiten laden um einiges langsamer mit der Puma Connect Box als mit dem Cisco EPC3212 :traurig:

 

[Andreas1969]

Webseiten laden um einiges langsamer mit der Puma Connect Box als mit dem Cisco EPC3212 :traurig:

Ist ja wohl auch logisch. Schau dir doch mal die Latenzen in den Graphen an :winken:

 

[Menano]

Seit den gestrigen Wartungsarbeiten läuft mein Anschluss echt Porno.

Bisschen Paketverlust mit UDP Paketen.. aber damit kann ich leben solang der Ping stabil bleibt.

 

[Andreas1969]

Seit den gestrigen Wartungsarbeiten läuft mein Anschluss echt Porno.

Was hattest Du nochmal für'ne Box und welche FW

 

[Menano]

Was hattest Du nochmal für'ne Box und welche FW

Steht im Bild :zwinker: . Fritzbox 6490 mit FW 6.84. :winken:

 

[Andreas1969]

Steht im Bild . Fritzbox 6490 mit FW 6.84.

Ah ja, deshalb auch keine Ping Spices, FW 6.84 :super:

 

[nts]

Zu der Frage, ob das Problem inzwischen behoben ist, gab es in den letzten Tagen auch einen separaten Thread im DSL Reports Forum: [Equip] Intel Puma 6 chipset issue now solved?, tl;dr: Wenn man den Beteiligten Glauben schenkt, gibt es bisher noch keine endgültige Lösung, wobei Intel wohl offiziell weiter daran arbeit.

Möglicherweise hat AVM mit 6.84 nur einen der schon etwas älteren Treiber nachgereicht, die bei ICMP Paketen und DNS Lookups Besserung bringen? Wäre auf jeden Fall cool, wenn einer der Fritzbox Besitzer hier nochmal den Test mit Pingplotter (http://badmodems.com/PinrplotterInstructions.htm) durchführt. :smile:
Die hier im Thread durchgeführten Test sind imho nicht ausreichend um das Vorhandensein oder Nichtvorhandensein der Puma6-Latenzspikes nachzuweisen: TBB geht wohl über ICMP und hat mit dem 24h Monitoring einfach nicht die Auflösung um das besprochene Problem darzustellen; iperf zeigt vielleicht am Ende der Übertragung den gemessenen Jitter an, die für den Puma6 Bug typischen periodischen Spitzen (https://youtu.be/15cJ400yR_E) sieht man jedoch nicht. Beides sind gewiss tolle Tools zur Bestimmung der Verbindungsqualität, aber wenn ich mich nicht irre sind sie hier einfach nicht zielführend.
Der DSL Reports Test geht in die richtige Richtung, im zugehörigen Forum wird aber des öfteren angesprochen, dass dieser nicht wirklich verlässlich ist.

 

[F-orced-customer]

Pingplotter misst keinen jitter. Wieso sollte iperf3 den falsch messen? :kratz:

 

[nts]

Du siehst halt die Laufzeiten der einzelnen Pakte anstatt eines zusammengefassten Wertes am Ende einer längeren Messung.
Jitter kann viele Ursachen haben, der des Puma6 Bugs zeigt sich aber durch ein charakteristisches Muster. Oder woher weißt du wie viel der Bug zu deinem Endergebnis beiträgt?

 

[F-orced-customer]

Vom Vergleich mit anderen iperf3 usern.

 

[nts]

Der Vergleich mit komplett anderen Anschlüssen bringt doch überhaupt nichts. Ich kann dir zeigen, dass ich mit meinem EPC3212 unter den richtigen Bedingungen genauso gut Jitter und Packetloss in iperf habe. Schließt du etwa daraus auch, dass man den Puma6 Bug auf Broadcom Chips reproduzieren kann? :kratz:
Der Typ hinter badmodems.com hat sich mit der Problematik wohl deutlich mehr beschäftigt als wir alle hier zusammen. Warum also das Rad neu erfinden wollen anstatt auf eine bewährte und eindeutige Methode zurückzugreifen?

 

[F-orced-customer]

Der Vergleich mit komplett anderen Anschlüssen bringt doch überhaupt nichts. Ich kann dir zeigen, dass ich mit meinem EPC3212 unter den richtigen Bedingungen genauso gut Jitter und Packetloss in iperf habe.

Zeig mal.

Packet loss hab ich mit iperf3 nur wenn ich mit -P über die Kappungsgrenze des Kabelmodem- upstreams steure.

Und was anderes als Vergleichen tut badmodems.com auch nicht und Dein "Muster" ist hier nicht erkennbar und iperf misst keinen jitter, erst iperf3:
http://badmodems.com/images/VS.gif

 

[nts]

Ja, die vergleichen aber am selben Anschluss. Ist auch nicht "mein Muster". Hast du das Video gesehen? Mal in deren Forum geschaut?

 

[F-orced-customer]

OK, aber Pingplotter Pro wollte hier keiner nehmen und ich hab kein windos.

Wo steht, dass die am selben Anschluss messen, oder schalten Kabelanbieter seit neuestem mehrere Modems per Kunde frei? :kratz:

 

[nts]

Ich nehme an in Amerika ist man uns technisch weit voraus und man kann ohne lange Warteschleife sein Modem registrieren Das von dir verlinkte Bild ist ja wohl ein einziger Screenshot und der dicke rote Balken der Packetloss während des Modemwechsels.
Willst du vielleicht mal mit hping experimentieren? Das sah als Alternative für Linux ziemlich vielversprechend aus