Diverses: 6490, 6590, Puma6-Probleme bei anderen Herstellern, Puma7-Design

[PeterPawn]

Das Folgende hatte ich - weil ich gerade im "flow" war - in diesem Beitrag geschrieben ... da gehört es aber definitiv nun erst recht nicht hin (schon der Rest ist "grenzwertig" in Bezug auf das Thema des Threads) und so habe ich das einfach mal abgetrennt und in einen eigenen Thread gepackt. Dabei ist mir allerdings auch wieder aufgefallen, daß es im AVM-(Hardware-)Unterforum praktisch keinen Thread kein Unterforum gibt, wo das wirklich passen würde, weil der das sich explizit mit den DOCSIS-Modellen befaßt. Auch die anderen 6490-Threads ziehen sich ja von der AVM-Hardware bis zum Kabel-Internet bei irgendeinem Provider durch die verschiedenen Unterforen - vielleicht ist es ja doch sinnvoll, für die DOCSIS-Modelle ein eigenes Unterforum einzurichten. Inzwischen ist das ja kein "Tabu-Thema" mehr, wie es das einmal war.

---

-Bei der anderen - nunmehr vielleicht finalen - "Ankündigung" in Gestalt der 6590 (die kriegt halt auch immer mehr etwas "Yeti-haftes" mit jeder neuen Ankündigung) bin ich auch schon gespannt ... bisher hatte ich ja noch die Vermutung, daß AVM die 6590 nun wieder wegen der Probleme mit dem "lagging" beim Puma6 weiter verzögert (dazu komme ich gleich noch), aber nun soll ja wohl auch dieses Modell im Juni (am 30.05. beginnt die dreitägige ANGACOM) nach nunmehr zwei Jahren tatsächlich erscheinen. Wofür ich bisher noch keine belastbare Quelle gefunden habe, wäre die Frage, ob die nun mit USB3 aufwarten wird - der Puma6-Chipsatz hat m.W. eigentlich nur USB2 eingebaut und so müßte man USB3 wohl analog zur 7490 mit einem gesonderten Controller umsetzen oder das Ding dümpelt weiterhin mit USB2 vor sich hin, auch wenn das bei der 6490 wenigstens auf dem x86-Core geschieht.

Wobei ich schon immer mal wissen wollte, ob jemand hier in D eigentlich eine entsprechende Messung der Latenzen beim Puma6 auch für die AVM-Boxen mal gemacht hat ... die Probleme wurden in den USA ja Anfang Dezember 2016 publik und betrafen mehrere Hersteller mit Puma6-Geräten - inkl. Hitron und Arris (Motorola) und diverse "Rebrands". Dem Vernehmen nach hat Intel dann zusammen mit den Geräteherstellern einen Fix erarbeitet (worin der bestand, habe ich bisher auch noch nicht definitiv(!) finden können) und der wurde dann dort von den KNB auch verteilt. Ich dachte ja schon, daß die von AVM Anfang Januar 2017 dann veröffentlichte 06.64 für die 6490 sich diesem Problem widmen würde ... aber auch da sind die Informationen ja praktisch "nicht vorhanden" und ich habe zumindest keine vordergründigen Änderungen an dieser Stelle (das "Verlagern" von Aufgaben auf einen anderen Core) gefunden - ist aber auch schwer und nicht sehr verläßlich als Aussage.

Es könnte ja sogar sein, daß die 6490 von dem Problem gar nicht wirklich betroffen ist, weil natürlich AVM an dieser Stelle nur den eCM-Teil aus dem Intel-CEFDK auch tatsächlich benutzt (schon beim eMTA (in den Provider-Versionen) würde ich behaupten, daß nur der SNMP-Stack dort von Intel stammt und die eigentliche Telefonie-Implementierung komplett durch AVM ersetzt wurde) ... wenn ich das richtig verstanden habe bzw. wenn die anfänglichen Vermutungen stimmten, war die Ursache bei den Geräten in den USA die zu große temporäre Auslastung des x86-Teils, der bei anderen Herstellern (mit weiter an Intel angelehnter Firmware) wohl auch für das Routing ins LAN zuständig ist (das Netzwerk kontrolliert bei AVM m.E. komplett der ARM-Core):

The problem appears to be that the x86 CPU in the modem is taking on too much work while processing network packets. Every couple of seconds or so, a high-priority maintenance task runs and it winds up momentarily hogging the processor, causing latency to increase by at least 200ms and, over time, about six per cent of packets to be dropped. It affects IPv4 and IPv6 – and it spoils internet gaming and other online real-time interaction that need fast response times.

Wenn das wirklich nur eine falsche Verteilung der Aufgaben bzw. eine "maintenance task" mit hoher Priorität war, dann betrifft/betraf das die 6490 wohl eher nicht ... wenn es aber irgendwelche Priorisierungen beim DMA-Zugriff oder bei der "Sortierung" und dem Routing von Interrupts waren, dann würde es vielleicht auch die 6490 betreffen ... man müßte halt mal selbst entsprechend messen (und sich die Zeit dafür nehmen) - das "Verfahren" ist z.B. im oben verlinkten Artikel bei TheRegister beschrieben.

Wobei es beim Puma7 dann erst richtig spannend wird ... mir ist letztens dann doch noch ein Link für ein Marketing-Papier von Intel untergekommen (als ich eigentlich nach dem GRX350 gesucht hatte): https://networkbuilders.intel.com/docs/Cable-Residential-Gateway-Solution-for-Converged-Networks.pdf - und nach dem, was da in Bezug auf das "Reference Design Kit" zu lesen ist (Seite 7 und 8), bietet Intel zu diesem Chipset dann praktisch den kompletten Software-Umfang an, den man in so einem "residential gateway" heutzutage erwarten würde. [ Auch dürfte das Prinzip-"Schaltbild" für den Puma6 sich nicht so sehr von dem für den Puma7 dort unterscheiden, falls jemand schon immer mal nach einer Idee gesucht hat, wie das wohl miteinander spielen mag. ]

Wenn das auch noch alles funktioniert, dann dürfte AVM vor der Frage stehen, wie man das mit den eigenen Closed-Source-Bestandteilen zusammenbringt und wieviel man dann von der Intel-Software nachbaut oder ob man es einfach wegläßt. Auf alle Fälle dürfte AVM dann mit dem Erscheinen von (vollständigen) Referenz-Implementierungen mit dem Puma7 auch wirklich Konkurrenz bekommen und wenn dann die Intel-Implementierung einer Funktionalität (z.B. IPv6) am Ende auch noch besser sein sollte als die von AVM (da gibt es ja schon ein paar Besonderheiten bei AVM, von DHCP über DNS bis SIP), dann wird vielleicht in der Zukunft die Luft auch dünner. Ich hoffe jedenfalls mal, daß die bisherige Zurückhaltung anderer Hersteller auch mit dem Warten auf den Puma7 zu erklären ist ... das oben verlinkte Intel-Dokument ist ja erst ca. 6 Monate alt (Okt. 2016) und - auch wenn es sicherlich Referenz-Designs und Vorabversionen geben wird - so ein "Wurf" dauert sicherlich seine Zeit.

 

[fesc]

Sehr komisch das ganze.

Ich kenne ja die anderen Designs nicht, aber warum sollte irgendein nicht-WiFi traffic ueber einen der CPU cores fliesen (bei der 6490 tut er das nicht)? Dazu ist doch der Packet-processor und der Switch im Puma da, und die CPU cores sind wohl zu schwach (ARM auf jeden Fall, Atom wenn er noch anderes zu tun hat).
Nach Aussen hat puma6 nur zwei rgmii ports ueber den internen switch, d.h. LAN/WAN traffic muss nie ueber die CPUs.

Im Artikel steht auch nicht ob es sich um LAN oder Wifi traffic handelt. Ich selbst habe solche Probleme noch nie gesehen (und andere wohl auch nicht).
Ich habe erst vor kurzem einen ping-test gemacht bei dem die latenzen graphisch dargestellt wurden, das sah sehr flach aus (30-40ms).

Das ganze scheint also ein reines Softwareproblem von Intel/den anderen Herstellern zu sein.
Oder der root cause ist in dem Artikel falsch beschrieben.

 

[PeterPawn]

Ich mag mich irren, aber das Packet-Processing im Offloading (also die "beschleunigte Verarbeitung" für R-NAT) wirkt m.E. nur auf eingehenden Verkehr - und der Beschreibung nach gehen ja sogar gesendete Pakete verloren (bis zu 6%, was natürlich bei FPS schon zu Problemen führen kann). Das ist ja bei stark asymmetrischer Verteilung der Datenraten auch nicht wirklich ein Problem - die 12 MBit/s, die m.W. bisher in D nur angeboten werden (bei einer 200/12-"Leitung"), sollte eine 6490 auch ohne Beschleunigung stemmen können. Die anderen Probleme, die sich aus hoher Auslastung der Prozessoren ergeben (z.B. eine "unresponsive box" bei hohem VPN-Aufkommen, wo der ARM-Core zu tun hat), hat man bei der 6490 auf alle Fälle auch (wie die Latenzen dann aussehen, habe ich aber auch noch nie gemessen) ... das weiß ich aus eigenem Erleben. Wenn ich über meinen 100/6-Anschluß bei KDG einen Film über eine VPN-Verbindung zu einem DSL 50/10 übertrage, ist die 6490 praktisch tot. Der Router arbeitet zwar noch, aber das komplette GUI reagiert nur noch "in Zeitlupe" und selbst das ist übertrieben, weil es einen kontinuierlichen Ablauf suggeriert - das ist aber eher "Stottern", was dabei herauskommt.

Bei dem Test in den USA wurde aber auch kein "normaler" Ping-Test gemacht:

[...] the graphs show an ICMP ping running 33 times a second over 30 minutes to his ISP's DNS server.

Wenn der Anstieg der Latenz sich im Bereich zwischen 100 und 200 ms bewegt, dann bringt ein "normaler" Ping-Test mit einem Paket pro Sekunde (wenn überhaupt, auch "interleaving" war bei Dir vermutlich nicht in Verwendung?) auch nicht so viel als Vergleich.

Bei 33 Paketen pro Sekunde (schon "krumm" der Wert, aber wohl passend zur "üblichen" Latenz gewählt) muß ja zwangsläufig das nächste Paket schon lange gesendet werden, wenn die Antwort auf das erste noch gar nicht eingetroffen ist - jede RTT > 30,3 ms würde dazu führen, daß mind. zwei "ausstehende" Pakete unterwegs sind und bei 200 ms Latenz sind es dann sogar 6 bis 7, die in dieser Zeit gesendet und empfangen werden müßten. Das kann m.W. kein übliches "ping"-Kommando - ich nehme aber Tipps in der Richtung gerne entgegen.

Weil das eben nicht mehr so einfach mit einem "ping" zu machen ist, habe ich das auch nur oben "angetextet" und noch nicht selbst probiert ... man braucht halt ein passendes Programm, das sowohl die notwendige Frequenz beim (regelmäßigen und stoischen) Senden von ICMP-Echo-Requests erreicht als auch - normalerweise anhand des Inhalts eines gesendeten Pakets, der ja als Reply zurückkommen sollte - die jeweilige Antwort dem ausgesendeten Request zuordnen kann und so die RTT für einen speziellen Request auch exakt (zumindest mit der notwendigen Auflösung) ermitteln kann.

Wenn jemand eine passende Software kennt und die ist auch noch "open source", dann teste ich das auch mal selbst ... aber ich habe im Moment weder Zeit noch Lust, selbst Entsprechendes zu programmieren.

 

[robert_s]

Wofür ich bisher noch keine belastbare Quelle gefunden habe, wäre die Frage, ob die nun mit USB3 aufwarten wird - der Puma6-Chipsatz hat m.W. eigentlich nur USB2 eingebaut

Das sollte belastbar genug sein:
https://avm.de/presse/presseinforma...-kabel-ausbau-von-fritzwlan-mit-mesh-komfort/

20.03.2017
[...]
FRITZ!Box 6590 Cable
[...]

• 2 USB 2.0-Ports

Wenn jemand eine passende Software kennt und die ist auch noch "open source", dann teste ich das auch mal selbst ... aber ich habe im Moment weder Zeit noch Lust, selbst Entsprechendes zu programmieren.

Was ist denn mit diesem Online-Test, der von dem "Entdecker" im DSLreports-Forum verlinkt ist:

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

Hast Du den mal ausprobiet?

Das ist ja bei stark asymmetrischer Verteilung der Datenraten auch nicht wirklich ein Problem - die 12 MBit/s, die m.W. bisher in D nur angeboten werden (bei einer 200/12-"Leitung"), sollte eine 6490 auch ohne Beschleunigung stemmen können.

? Es gibt doch schon 25 und vereinzelt auch 50Mbps Upstream, und wenn ich mich recht erinnere, schrieb einer von den wenigen "Auserwählten" für letzteres, dass er den mit einer 6490 betreibt.

Bei 33 Paketen pro Sekunde (schon "krumm" der Wert, aber wohl passend zur "üblichen" Latenz gewählt) muß ja zwangsläufig das nächste Paket schon lange gesendet werden, wenn die Antwort auf das erste noch gar nicht eingetroffen ist - jede RTT > 30,3 ms würde dazu führen, daß mind. zwei "ausstehende" Pakete unterwegs sind und bei 200 ms Latenz sind es dann sogar 6 bis 7, die in dieser Zeit gesendet und empfangen werden müßten. Das kann m.W. kein übliches "ping"-Kommando - ich nehme aber Tipps in der Richtung gerne entgegen.

Weil das eben nicht mehr so einfach mit einem "ping" zu machen ist, habe ich das auch nur oben "angetextet" und noch nicht selbst probiert ... man braucht halt ein passendes Programm,

An den Screenshots aus dem dslreports-Forum sieht man ja, was der "Entdecker" verwendet hat:

https://www.dslreports.com/speak/sl...kZW0tSW50ZWwtUHVtYS02LU1heExpbmVhci1taXN0YWtl

Eine Bezahlware namens "MultiPing", anscheinend auf einem sehr alten Windows - sieht nach Windows 2000 aus. Ich habe da dunkel im Hinterkopf, dass die damaligen Windows-Versionen nicht besonders präzise auflösende Timer hatten...

Ich habe dieses "MultiPing" mal auf einem Windows 10 "Creators Update" ange-Trial-t - und es erwies sich als funktionsuntüchtig. Jedenfalls habe ich einen anzupingenden Server ausgewählt, auf den "Start"-Button geklickt, aber es tat sich nichts. Auch nicht mit Admin-Rechten (falls das "raw sockets" verwenden sollte, welche in Windows irgendwann nur noch mit Admin-Rechten erstellbar waren).

 

[error_403]

Das Latenz Problem ist schon länger bekannt aber ich würde dies nicht "nur" dem Puma Chip zuschreiben.
Dies ist stark abhängig von der eingesetzten CMTS. Zumal man diesem Entgegenwirken kann in dem man es anpasst (TLV 24.35) und Active Queue Management.
Es gibt dazu bei Cablelabs in der MULPI Spec einen Absatz über Upstream Buffer Control, bei Arris auch seit Rev 3.5 dabei.
Bei Cisco ist es nach meinem Kenntnissstand nicht aufgefallen bisher.

Edit: Aber das der puma unter Last Probleme hat ist bisher nicht gänzlich gelöst dadurch.

 

[robert_s]

Dies ist stark abhängig von der eingesetzten CMTS. Zumal man diesem Entgegenwirken kann in dem man es anpasst (TLV 24.35)

TLV 24.35 finde ich nicht in der aktuellen MULPI vom 11. Januar 2017, weder für DOCSIS 3.0 noch für DOCSIS 3.1. Bei beiden geht es nur bis TLV 24.26.

 

[error_403]

Hab es gerade nur von Cisco, parat.
https://www.cisco.com/c/en/us/td/docs/cable/cmts/config_guide/b_cmts_ds_us_features/b_cmts_ds_us_features_chapter_010.html
http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf


Edit: War ne einzelne Spec, dachte war in der MULPI
https://apps.cablelabs.com/specification/cable-modem-buffer-control

 

[fesc]

Ich mag mich irren, aber das Packet-Processing im Offloading (also die "beschleunigte Verarbeitung" für R-NAT) wirkt m.E. nur auf eingehenden Verkehr - und der Beschreibung nach gehen ja sogar gesendete Pakete verloren (bis zu 6%, was natürlich bei FPS schon zu Problemen führen kann).

Ich denke dem ist nicht so. Wenn ich einen speedtest mache der meine 80/4 Leitung voll auslastet, dann kommen hier keine pakete in beiden cores an, und die CPU last ist stabil niedrig.

Ich habe ein tool geschrieben bei dem ich die internen L2 switch counter monitoren kann (Port 0: Atom core, Port 2: Atheros switch, port 7: DOCSIS; Was die counter im einzelnen sind habe ich noch nicht untersucht, aber man kann es sich hier ja denken). Bei upload sieht das so aus

 0: Counter1                : +142                     15,952,250 124/sec
 0: Counter2                : +142                     15,952,250 124/sec
 0: Counter5                : +10,508               2,648,857,372 9,187/sec
 0: Counter6                : +285                     29,960,102 249/sec
 0: Counter7                : +285                     29,960,102 249/sec
 2: Counter1                : +379                      5,008,088 335/sec
 2: Counter2                : +379                      5,008,088 336/sec
 2: Counter5                : +556,912                759,275,652 500,618/sec
 2: Counter6                : +221                     12,095,650 199/sec
 2: Counter7                : +221                     12,095,650 199/sec
 2: Counter8                : +16,988               2,949,895,893 15,356/sec
 7: Counter1                : +491                     39,987,673 447/sec
 7: Counter2                : +491                     39,987,673 447/sec
 7: Counter5                : +439,837              2,509,266,631 400,809/sec
 7: Counter6                : +549                     19,277,491 498/sec
 7: Counter7                : +549                     19,277,491 497/sec
 7: Counter8                : +622,386              3,027,752,612 561,910/sec

Bei Download so:

 0: Counter1                : +431                     15,951,266 384/sec
 0: Counter2                : +431                     15,951,266 384/sec
 0: Counter5                : +40,576               2,648,773,890 36,235/sec
 0: Counter6                : +467                     29,956,898 417/sec
 0: Counter7                : +467                     29,956,898 417/sec
 2: Counter1                : +3,815                    5,004,118 3,406/sec
 2: Counter2                : +3,815                    5,004,118 3,406/sec
 2: Counter5                : +265,920                755,632,138 237,456/sec
 2: Counter6                : +7,100                   12,090,949 6,340/sec
 2: Counter7                : +7,100                   12,090,949 6,352/sec
 2: Counter8                : +10,782,320           2,945,027,736 9,646,959/sec
 7: Counter1                : +7,530                   39,979,937 6,790/sec
 7: Counter2                : +7,530                   39,979,937 6,790/sec
 7: Counter5                : +11,432,282           2,499,765,210 10,321,269/sec
 7: Counter6                : +4,235                   19,272,623 3,813/sec
 7: Counter7                : +4,235                   19,272,623 3,815/sec
 7: Counter8                : +323,338              3,023,970,302 292,213/sec

Wie man sieht geht kein traffic an den Atom, der ja angeblich das problem machen soll. Wie gesagt, bei Wifi sieht das anders aus, da geht der traffic ueber die lan bridge im Atom.

Das ist ja bei stark asymmetrischer Verteilung der Datenraten auch nicht wirklich ein Problem - die 12 MBit/s, die m.W. bisher in D nur angeboten werden (bei einer 200/12-"Leitung"), sollte eine 6490 auch ohne Beschleunigung stemmen können. Die anderen Probleme, die sich aus hoher Auslastung der Prozessoren ergeben (z.B. eine "unresponsive box" bei hohem VPN-Aufkommen, wo der ARM-Core zu tun hat), hat man bei der 6490 auf alle Fälle auch (wie die Latenzen dann aussehen, habe ich aber auch noch nie gemessen) ... das weiß ich aus eigenem Erleben. Wenn ich über meinen 100/6-Anschluß bei KDG einen Film über eine VPN-Verbindung zu einem DSL 50/10 übertrage, ist die 6490 praktisch tot. Der Router arbeitet zwar noch, aber das komplette GUI reagiert nur noch "in Zeitlupe" und selbst das ist übertrieben, weil es einen kontinuierlichen Ablauf suggeriert - das ist aber eher "Stottern", was dabei herauskommt.

Hast du mal geschaut wir hoch da die Auslastung auf den cores ist? Es koennte ja auch ein Problem in den Datenpfaden sein.

Bei dem Test in den USA wurde aber auch kein "normaler" Ping-Test gemacht:

Wenn der Anstieg der Latenz sich im Bereich zwischen 100 und 200 ms bewegt, dann bringt ein "normaler" Ping-Test mit einem Paket pro Sekunde (wenn überhaupt, auch "interleaving" war bei Dir vermutlich nicht in Verwendung?) auch nicht so viel als Vergleich.

Den test habe ich mit einem online speedtest gemacht (wieistmeineip). Der zeigt zumindest ueber einen kurzenzeitraum den Verlauf an, aktuell stabil bei 30ms.

Das gleiche wenn ich dorthin einen ping von einem lokalen rechner mache (ping -i0 -l10 ...). Stabil bei 30-40ms (fuer ein paar sekunden, dann gibt es immer einen sekundendelay, wohl DOS schutz).

Aber du hast recht, um das um das genau zu testen braeuchte man wohl einen Mietserver ...

Edit: zu meinem lokalen kabelgateway (ping -i0 -l8 -f -A):
rtt min/avg/max/mdev = 7.874/12.693/19.412/2.573 ms, pipe 8, ipg/ewma 13.025/13.950 ms



P.S.: Mein aktuelles Blockdiagram wird gem. neuester Erkenntnisse ergaenzt auf MISC.md in meinem repository.

 

[robert_s]

Edit: War ne einzelne Spec, dachte war in der MULPI
https://apps.cablelabs.com/specification/cable-modem-buffer-control

Ah, es ist doch in der MULPI, nur mit der Suchfunktion nicht zu finden, weil es als "[24].35" in Kapitel C.2.2.7.11.1 "Upstream Buffer Control" steht.

- - - Aktualisiert - - -

Das Latenz Problem ist schon länger bekannt aber ich würde dies nicht "nur" dem Puma Chip zuschreiben.
Dies ist stark abhängig von der eingesetzten CMTS.

Solche Einflüsse könnte man ja mit der Einstellung "Internet über LAN1" ausschliessen. Die Frage ist, wie dann die Datenflüsse durch die 6490 aussehen. Wenn das auch durch die "auffällige" Komponente geht, hätte man damit eine schöne Spielwiese, indem man die 6490 einfach mal zwischen 2 PCs im LAN (oder vielleicht auch nur einen mit 2 LAN-Ports?) hängt, und dann nach Herzenslust bis zu 1/1 Gbps durch die Kiste jagt, um zu sehen, was die so aushält...

 

[fesc]

Solche Einflüsse könnte man ja mit der Einstellung "Internet über LAN1" ausschliessen. Die Frage ist, wie dann die Datenflüsse durch die 6490 aussehen. Wenn das auch durch die "auffällige" Komponente geht, hätte man damit eine schöne Spielwiese, indem man die 6490 einfach mal zwischen 2 PCs im LAN (oder vielleicht auch nur einen mit 2 LAN-Ports?) hängt, und dann nach Herzenslust bis zu 1/1 Gbps durch die Kiste jagt, um zu sehen, was die so aushält...

Ich nehme an das der LAN1 port in dem fall ein eigenes VLAN im externen switch bekommt, und im internen switch zunaechst an den DOCSIS port bebridged wird. Ab da die gleichen Datenpfade.
Ich wollte das schon testen, aber ich kann meine Box nicht eben mal von Netz nehmen. Wuerde mich aber auch interessieren, wer es machen kann: "athtool -V" auf dem ARM core.

Traffic zwischen 2 LAN ports geht nur ueber den externen switch, da ist der Puma gar nicht involviert. Wuerde mich schockieren wenn es da einen Engpass gaebe.

 

[PeterPawn]

Das "MultiPing" kannte ich bisher nicht, nicht einmal den Namen ... ich hatte immer nur Bilder gesehen, die auf den Canvas der Plots reduziert waren.

Schaut man sich die mit VPN ausgelastete Box (den ARM-Core) mit "top" an:

Mem: 118872K used, 134548K free, 0K shrd, 10080K buff, 37312K cached
CPU:  8.0% usr 13.7% sys  0.0% nic  8.5% idle  0.0% io  0.0% irq 69.5% sirq
Load average: 2.73 2.81 1.91 2/158 20307
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  714     1 root     S     5736  2.2   0 14.2 /usr/sbin/pcd -f /etc/scripts/dsdk.pcd -v -p -t 20 -e /nvram/pcd_error_log.txt
20252     2 root     SW       0  0.0   0 13.9 [kworker/0:0]
  988     1 root     S     3976  1.5   0  8.5 multid
20244 20241 root     R     1272  0.5   0  3.2 top
  728   714 root     S     6268  2.4   0  2.1 /usr/sbin/gptimer --timer-tick=50
  745   714 root     S     5796  2.2   0  2.1 /usr/sbin/extswitchwatch
  522     2 root     SW<      0  0.0   0  1.7 [avm_dect_thread]
 1031   714 root     S    58012 22.8   0  0.8 /usr/sbin/downstream_manager 24 28
 1072   714 root     S    58940 23.2   0  0.7 /usr/sbin/snmp_agent_cm -c /etc/agent_cm.cnf -n
 1037   714 root     S    58012 22.8   0  0.7 /usr/sbin/downstream_manager 18 22
  891   714 root     S    58008 22.8   0  0.7 /usr/sbin/mlx -d DOCINT -n 7
 1032   714 root     S    58012 22.8   0  0.5 /usr/sbin/downstream_manager 23 27
 1033   714 root     S    58012 22.8   0  0.5 /usr/sbin/downstream_manager 22 26
 1042   714 root     S    58012 22.8   0  0.5 /usr/sbin/downstream_manager 13 17
   20     2 root     SW       0  0.0   0  0.5 [irq/13-arm_atom]
 1281     1 root     S    59356 23.3   0  0.3 dvbipcd
 1039   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 16 20
 1035   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 20 24
 1040   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 15 19
 1038   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 17 21
 1046   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 5 9
 1047   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 4 8
 1049   714 root     S    58012 22.8   0  0.3 /usr/sbin/downstream_manager 2 6
 1024     1 root     S     7876  3.1   0  0.3 dsld -i -n
 1098     1 root     S     5272  2.0   0  0.3 telefon a127.0.0.1
  287     2 root     SW       0  0.0   0  0.3 [pm_info]
    3     2 root     SW       0  0.0   0  0.3 [ksoftirqd/0]
  516     2 root     SW       0  0.0   0  0.3 [pcmlink_ctrl]
  964   714 root     S    58168 22.9   0  0.1 /usr/sbin/dispatcher
 1034   714 root     S    58012 22.8   0  0.1 /usr/sbin/downstream_manager 21 25
 1036   714 root     S    58012 22.8   0  0.1 /usr/sbin/downstream_manager 19 23
 1041   714 root     S    58012 22.8   0  0.1 /usr/sbin/downstream_manager 14 18
 1043   714 root     S    58012 22.8   0  0.1 /usr/sbin/downstream_manager 8 12
 1045   714 root     S    58012 22.8   0  0.1 /usr/sbin/downstream_manager 6 10
  883   714 root     S    57992 22.8   0  0.1 /usr/sbin/hal_cmd_mbox
 1117     1 root     S     8484  3.3   0  0.1 voipd
  982     1 root     S     6104  2.4   0  0.1 upnpd
 1005     1 root     S     3280  1.2   0  0.1 ddnsd
 1731     1 root     S     3128  1.2   0  0.1 usermand
  947     1 root     S     2460  0.9   0  0.1 avmipcd
 1273     1 root     S     1260  0.5   0  0.1 /usr/sbin/telnetd -l /bin/sh

, dann geht die meiste Zeit in der IRQ-Behandlung drauf (nur Prozesse mit einer CPU-Nutzung > 0 zu diesem Zeitpunkt sind in der Liste oben) ... m.E. verbirgt sich dahinter aber die Verschlüsselung. Der "process control daemon" von Intel und die Worker-Threads im Kernel-Pool bringen jedenfalls nur ca. 1/3 der Auslastung und die ist am Ende dann doch so heftig (sicherlich auch wegen geringer Priorität des HTTP-Servers (ctlmgr) an dieser Stelle), daß eine "normale" Anmeldung vom ersten Seitenaufruf bis zum "Erscheinen" der Übersicht dann dieses Timing erzeugt im Firefox (geteilt an der Stelle, wo die Kennwort-Eingabe erfolgt, damit diese Zeit nicht berücksichtigt wird):


Die Zeitskale beginnt beim Aufruf der Übersichtsseite wieder bei 0 - in der Summe sind das also mehr als 60 Sekunden vom Aufruf der Login-Seite bis zur Anzeige der ersten Übersicht. Sicherlich spielt es hier auch eine Rolle, daß AVM mit dem "ctlmgr" und der VPN-Verschlüsselung auf demselben System (der "avmike" richtet ja nur die SAs ein, aber auch der würde auf dem ARM-Core laufen) arbeitet ... m.W. verwendet das GUI von Intel eigentlich den x86-Core (APP) anstelle des ARM-Cores (NP), zumindest bilde ich mir ein, das mal in Hitron-Geräten so gesehen zu haben.

Aber die Screenshots illustrieren das, was ich weiter oben meinte ... die Box wird "unresponsive", arbeitet aber durchaus noch erfolgreich als Router. Wie das mit paralleler Telefonie dann aussieht, mußte ich bisher glücklicherweise noch nicht selbst testen ... ich benutze die SIP-Accounts bei VF/KD praktisch nicht und die 6490 hat die Telefonie mehr als Alibi konfiguriert.

Der Puma6-Test bei DSLReports sieht (bei arbeitender VPN-Verbindung) richtig gut aus:

Aber das ist bei mir ohnehin kein wirklich valider Test, weil da zuviele interne Systeme noch beteiligt sind, wenn ich eine externe Webseite im Browser aufrufe. Selbst bei inaktiver VPN-Verbindung (im Moment läuft eine Übertragung, daher kann ich keinen Screenshot machen) liefert dieser Test (sicherlich auch wegen der verwendeten Server jenseits des Atlantik) recht hohe RTT-Werte (um die 50 ms) für eine DOCSIS-Anbindung.

 

[Shirocco88]

Mem: 118872K used, 134548K free, 0K shrd, 10080K buff, 37312K cachedCPU:  8.0% usr 13.7% sys  0.0% nic  8.5% idle  0.0% io  0.0% irq 69.5% sirqLoad average: 2.73 2.81 1.91 2/158 20307  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND 1273     1 root     S     1260  0.5   0  0.1 /usr/sbin/telnetd -l /bin/sh

diese Kiste ist ja von LAN-Seite "via Port 23/tcp für Fernsteuerung komplett offen"

 

[PeterPawn]

Ansonsten wurden in den USA ja die Arris-Modelle direkt gegeneinander gestellt und damit der Einfluß der CMTS-Konfiguration (solange das CM nicht auch abweichend von dort konfiguriert wird nach seinem Typ und unterschiedliche QoS-Parameter provisioniert werden) ja eliminiert ... einer der (zuvor von mir nicht angesehenen) Screenshots bei DSLReport zeigt ja in einem einzigen Plot die Gegenüberstellung von SB6183 (ich tippe einfach mal auf Puma5, habe aber absolut keine gesicherten Informationen und auch gar nicht erst danach gesucht) und SB6190 an demselben Anschluß.

Damit stellt sich m.E. die Frage nach dem Einfluß von "Buffer Control" oder "AQM" (im CM) eigentlich nicht (jedenfalls nicht bei der Frage, warum das gerade beim Puma6 so eklatant zutage tritt) ... es sei denn - und das wäre vielleicht auch noch eine Erklärung, wo dann aber die Vermutung/Begründung bei "The Register" auch daneben läge in meinen Augen -, daß das Problem beim Puma6 genau an dieser Stelle (Buffer Control, Scheduler-Implementierung bei AQM) lag. Das wäre aber m.W. auch bei AVM noch der Code von Intel, der das alles "ab CM" steuert.

- - - Aktualisiert - - -

Der Service ist normalerweise gar nicht aktiv und wird nur bei Bedarf gestartet ... aber danke für den Tipp, daß man einen Telnet-Server in dieser Form besser nicht dauerhaft laufen läßt. ;-)

 

[fesc]

Interessant ist mein speed test Ergebnis bei dsltest.
BufferBloat bekommt ein glattes F. Das ist ja das was mit "cable modem buffer control" eigentlich verhindert werden soll. Die Frage ist nur welcher teil der strecke das Problem ist.

Wie das mit paralleler Telefonie dann aussieht, mußte ich bisher glücklicherweise noch nicht selbst testen ... ich benutze die SIP-Accounts bei VF/KD praktisch nicht und die 6490 hat die Telefonie mehr als Alibi konfiguriert.

Ich hatte mal den fall dass ich extrem schlechte qualitaet beim telefonieren hatte, bis ich gemerkt habe dass ich gleichzeitig ein grosses file via scp auf den arm core geschoben habe ....

 

[robert_s]

einer der (zuvor von mir nicht angesehenen) Screenshots bei DSLReport zeigt ja in einem einzigen Plot die Gegenüberstellung von SB6183 (ich tippe einfach mal auf Puma5, habe aber absolut keine gesicherten Informationen und auch gar nicht erst danach gesucht) und SB6190 an demselben Anschluß.

Schmach und Schande! In dem direkt von Dir verlinkten theregister-Artikel steht es doch fett über den Screenshots:

Broadcom-based Arris SB6183


Intel-based Arris SB6190

Für jemanden, der stets anderen predigt, dass sie sich gefälligst erst einmal ordentlich einzulesen haben, ist da aber schon mal ein wenig schämen angesagt... Wobei ich den Anlass dafür eher in dem Predigen als in dem unzureichenden Lesen sehen würde.

 

[PeterPawn]

@robert_s:
Da reicht es wohl bei mir nicht mehr für die intellektuelle Leistung, die zwei Fundstellen (einmal den Beitrag bei "The Register" und einmal die Pictures bei "DSLReports") miteinander in Beziehung zu setzen - ist ja auch alles in Englisch.

Im Gegensatz zu manchem anderen schreibe ich aber auch deutlich dazu, wo ich etwas "vermute" und gebe meine Spekulationen nicht (zumindest nicht absichtlich und schon gar nicht häufig) als gesichertes Wissen aus. Ich habe mir das hier halt nicht gemerkt und hatte gar keine Lust zum Recherchieren ... viel deutlicher, als ich genau dieses in #13 zum Ausdruck gebracht habe, kann man es meines Erachtens auch nicht mehr schreiben - da denke ich nicht einmal im Traum daran, mich zu schämen. Wenn das für die eigentliche Aussage tatsächlich eine Rolle gespielt hätte, wäre es ggf. anders ... aber dann hätte ich vermutlich ohnehin gesucht.

Wenn Du also die Absicht haben solltest, mich mal wieder "von der Seite anzumachen" (für einen Scherz oder auch nur ein Augenzwinkern fehlt mir da jeder Hinweis, dafür ist die Überhöhung mit "Schmach und Schande" für mich nicht ausreichend angesichts der letzten Bemerkung und vergangener Auseinandersetzungen), sollten wir uns vielleicht besser aus dem Weg gehen oder Du suchst Dir einfach einen "Aufhänger", wo die reine Provokation als Selbstzweck nicht so offensichtlich zutage tritt.

 

[robert_s]

Wenn Du also die Absicht haben solltest, mich mal wieder "von der Seite anzumachen"

Nö, so verbissen sehe ich das nicht, eher als "kleinen Seitenhieb". Ansonsten bin ich für den Erkenntnisgewinn aus diesem Thread dankbar, auch wenn der mal wieder mit viel zu vielen Worten und falschen Schlagworten (um die 6590 ging es nur ganz am Rande) begonnen wurde.

Ich war auch von Anfang an von den hohen RTT-Schwankungen bei meinem DOCSIS-Anschluss enttäuscht (mit VDSL2 war das nicht so), konnte aber mangels Vergleichsmöglichkeiten auch nicht herausfinden, ob das nun an DOCSIS per se liegt oder ob da was mit der Technik nicht so ist, wie es sein sollte.

Leider habe ich hier auch nur Geräte mit Puma6-Chipsatz zur Hand (Vodafone hat mir eine Compal cbn CH7466CE als Leihrouter geschickt, welcher mit dem irgendwo in den Threads als ebenfalls von dem Problem betroffen erwähntem CH7465irgendwas eng verwandt sein dürfte), sodass ich mit meinen Geräten auch nicht herausfinden kann, ob man ohne Puma6 stabilere RTTs bekommt.

Aber vielleicht macht ja noch jemand den "Internet über LAN1" Test mit der 6490. Wenn sich da ein gut reproduzierbarer Aufbau findet, mit dem man einen Fehler/Mangel nachstellen kann, könnte man das ja mal bei AVM einwerfen, ob die das nicht nachstellen und beheben mögen...

 

[PeterPawn]

auch wenn der mal wieder mit viel zu vielen Worten und falschen Schlagworten (um die 6590 ging es nur ganz am Rande) begonnen wurde.

Die vielen Worte kann ich Dir leider nicht ersparen (die sind alt und müssen dringend verbraucht werden, damit neue Platz finden), ich schreibe nun mal lieber ein Wort mehr als eines zuwenig - da Dir mein "Problem" ja bekannt ist, könntest Du Dir ein Programm schreiben, welches (vielleicht nach lexikalischer Analyse?) meine Beiträge auf die für Dich wesentlichen Informationen komprimiert (so es etwas in der Richtung darin tatsächlich geben sollte - das wäre dann in meinen Augen "ein Seitenhieb") und das ist immer noch die bessere Alternative, da der umgekehrte Weg oft genug von anderen gegangen wird - irgendwo muß man ja einen "Wiedererkennungswert" haben.

Derartige Optionen habe ich anhand von #1 auch einmal angetestet, mit durchaus erheblichem Einsparpotential und so muß ich mir da vermutlich wirklich noch einmal Gedanken machen:

$ [COLOR="#0000FF"][B]cat - >ippf.txt[/B][/COLOR]
$ [COLOR="#0000FF"][B]wc -c ippf.txt[/B][/COLOR]
[COLOR="#FF0000"][B]6243 [/B][/COLOR]ippf.txt
$ [COLOR="#0000FF"][B]gzip -c9 < ippf.txt | wc -c[/B][/COLOR]
[COLOR="#FF0000"][B]3076[/B][/COLOR]
$ [COLOR="#0000FF"][B]lzma -c9 < ippf.txt | wc -c[/B][/COLOR]
[COLOR="#FF0000"][B]3068[/B][/COLOR]
$ [COLOR="#0000FF"][B]sed -e "s|[aeiouäöüAEIOUÄÖÜ]||g" ippf.txt | wc -c[/B][/COLOR]
[COLOR="#FF0000"][B]4371[/B][/COLOR]
$ [COLOR="#0000FF"][B]sed -e "s|[aeiouäöüAEIOUÄÖÜ]||g" ippf.txt | gzip -c9 | wc -c[/B][/COLOR]
[COLOR="#FF0000"][B]2294[/B][/COLOR]

Eine einfache RLE habe ich auch in Erwägung gezogen, aber die liefert dann auch nur recht schlechte Ergebnisse - dazu müßte man die verwendeten Worte vielleicht vorher alphabetisch sortieren (oder gar die Buchstaben), was dann allerdings das Lesen doch erheblich erschweren könnte. Die optimale Lösung zur Kürzung meiner Beiträge wäre also der Verzicht auf Vokale und parallel dazu die Verwendung von Kompression - wobei hier LZMA und ZIP in etwa dasselbe Ergebnis liefern und daher ZIP zu bevorzugen wäre. Oder ich habe "komprimiert" dann doch wieder falsch interpretiert ... alles ist möglich.

---

-Ich finde auch die 6590 im Titel nicht so falsch, wie Du das offensichtlich sehen möchtest ... erstens steht da deutlich "Diverses", zweitens erfolgte die "Herleitung" (i.V.m. dem anderen Thread) über die Verzögerungen bei neuen Modellen und deren Firmware-Qualität inkl. möglicher Ursachen für Verzögerungen und drittens hat die 6590 wohl auch einen Puma6, der nun eben davon betroffen sein könnte (was eine Verzögerung durch AVM erklären könnte) oder auch nicht.

Beim Pum6 in der 6590 muß ich aber auch "vermutlich" schreiben, es sei denn, ich hätte auch da irgendeine technische Spezifikation von AVM genauso "überlesen" wie die wenigen technischen Details der 6590 am Ende irgendeines langen (und m.E. langweiligen) Marketing-Artikels für Journalisten als Zielgruppe (denn etwas anderes sind solche Presseinformationen wohl auch nicht) - in der AVM-Website zur CeBIT und zur 6590 (hier: https://avm.de/cebit-2017/) habe ich jedenfalls keine Angaben gefunden, welchen Modus die zwei erwähnten USB-Ports nun bieten (und auch keine Links zu technischen Spezifikationen, aus denen das hervorgegangen wäre). Allerdings steht eben in der Presseinformation nicht ausdrücklich, daß die 6590 auf dem Puma6 basiert - auch das ist also (ausgehend von Fundstellen in den OSS-Paketen zur 6490) reine Spekulation und ich hoffe inständig, daß es nicht doch Broadcom sein wird - das wäre wirklich blamabel (auch für mich, wenn ich mich so "auf's Glatteis" locken lasse).

Wenn die 6590 verfügbar wäre, könnte man tatsächlich den Test zwischen einer 6490 mit 06.63, einer mit 06.64 und einer 6590 mit einer noch unbekannten Firmware-Version an ein und demselben Anschluß nachstellen und damit zumindest auch ermitteln, ob die Vermutung, die 06.64 könnte sich auch diesem Thema gewidmet haben, sich bestätigen läßt oder nicht.

 

[error_403]

die 6590 wohl auch einen Puma6, der nun eben davon betroffen sein könnte (was eine Verzögerung durch AVM erklären könnte) oder auch nicht

Glaube nicht an eine Verögerung, die ersten Boxen sind bei verschiedenen Netzbetreibern schon gesichtet wurden.

 

[fesc]

Die Frage ist nur welcher teil der strecke das Problem ist.

Ich habe mal getestet ob pings vom einem anderen rechner zum kabel-gateway genauso langsam gehen wie zum "dslreports" test server wenn der upload test laeuft.
Dazu ein simpler ping (vom atom core) auf das gateway gestartet waehrend dslreports test laeuft. Man sieht dass die ping latency genauso hoch (bis zu 3000ms!) ist wie das was dslreports anzeigt (und mir deshalb ein F gibt).

D.h. es ist tatsaechlich die fritzbox die dafuer verantworlich ist, nicht irgendeine Komponente auf der Strecke.

Es nuetzt auch nichts den "ping host" als priorisierte Anwendung zu definieren. Ich weiss nicht was diese Priorisierung machen soll, sie bewirkt auf jeden Fall nicht dass die frames in einer dedizierten queue am CM landen ...

Ich frage mich nur ob das jetzt was Kabel/puma-Spezifisches ist, oder ob das z.B. bei DSL im gleichen masse auftritt. Wobei, bei anderen ISPs (insbesodere UM) ist der anteil an "grade F" recht niedrig, scheint also evtl. doch am provider zu liegen.