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

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.

Zum Vergrößern anklicken....

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.

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 Register schrieb:

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

Zum Vergrößern anklicken....

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.

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:
, 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.

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. ;-)

@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 schrieb:

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

Zum Vergrößern anklicken....

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:
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.