- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,283
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
@error_403:
Mit der Verzögerung meinte ich auch mehr die bisher schon entstandene ... die erste Ankündigung erfolgte ja schon 2015 zur ANGACOM und seither läßt die 6590 auf sich warten. Das ist im Vergleich zu (auch später angekündigten) DSL-Modellen schon recht lange und so kann man eben spekulieren, was die Ursache der Verzögerung am Ende war.
Die anderen Änderungen in der 6590 (MU-MIMO in erster Linie) haben ja bei DSL-Modellen bereits Einzug gehalten - wobei natürlich auch hier mit den Hotspot-Funktionen (sicherlich über WIFI-GW realisiert bei VF und UM?) noch eine Besonderheit bei den DOCSIS-Modellen lauern könnte; aber das ist bei der 6490 auch schon so und das Tunneln spielt sich ja eher auf höheren Layern ab und sollte von den verwendeten WLAN-Chipsets unabhängig sein (mithin auch davon, ob das nun das "alte AC" mit einem Stream ist oder 4x4 mit MU-MIMO). Anders als bei der 7590 (aber das ist ein anderes Thema und ich lasse mich nur zu gerne eines Besseren belehren von AVM) glaube ich bei der 6590 jedoch tatsächlich daran, daß die um die ANGACOM herum in den Einzelhandel kommen könnte.
Die ersten auftauchenden Boxen in der Provisionierung würde ich eher bei AVM selbst bzw. den dortigen Mitarbeitern (auch daheim) "verorten" ... oder meintest Du wirklich, daß bereits KNB die 6590 selbst in ihren eigenen Netzen (in nennenswertem Umfang) durch Kunden oder meinetwegen eigene Mitarbeiter (außerhalb der Labore) testen lassen? An solchen Stellen staune ich immer wieder aufs Neue, wieso sich so etwas dann nicht herumspricht (nicht mal "andeutungsweise") - allen NDA oder ähnlichen Konstruktionen zum Trotz.
Das geht vom Mail-Admin bei einem Provider, wo ein Push-Service so einer Box eine entsprechende E-Mail hinterläßt (die ist m.W. immer noch unverschlüsselt) bis zum SIP-Server bei einem (externen) Anbieter, wo der User-Agent-Header dann in aller Regel nähere Informationen zum Modell enthält - da existieren so viele "Schwachstellen", die auch keinem NDA unterliegen und wo der Datenschutz schon sehr genau genommen werden müßte, wenn das nicht (notfalls anonym) nach außen dringt (logischerweise ohne Details), daß ich wirklich staune. Das heißt nicht, daß ich das schlecht finde ... es ist/wäre nur ungewöhnlich nach meinen eigenen Erfahrungen, auf welchen verschlungenen Wegen die Leute an solche Informationen gelangen. Dagegen sind die bekannten Fotographen für die "Erlkönige" in der Automobil-Industrie ja fast Waisenknaben, wenn es um "Findigkeit" einiger bei der Suche nach solchen Indizien im Netz geht.
@fesc:
Es hat sicherlich auch der Provider seinen Anteil an solchen Ergebnissen, wenn das Segment überlastet ist und es häufiger zu "congestion" am CMTS kommt.
Ich würde hier ohnehin (erneut ohne es zu wissen, nur rein aus "Überlegungen" und auf der Basis von Beobachtungen in den Supportdaten) annehmen, daß da zwei unabhängige QoS-Lösungen (hoffentlich) miteinander arbeiten. Das DOCSIS-QoS (vom Provider konfiguriert) sieht bei mir so aus (VF/KD 100/6):
Da sind also nur wenige "classifier" definiert und spaßigerweise auch bei einer Kundenbox, wo die 10.0.0.0/8 gar nicht verwendet wird soweit ich weiß (es gibt jedenfalls kein mta0 und auch kein anderes Interface, was eine solche Adresse hätte), zwei solche für dieses Subnetz (wenn auch nur für DHCP und SNMP in verschiedenen Richtungen). Mit den zwei Queues (oder "service flows") ist dann auch nicht so sehr viel zu priorisieren ... beide "best effort" und halt eine mit "priority 4", die vermutlich vor der anderen bedient werden wird, was sich vielleicht bei SIP (UDP 5060) bemerkbar machen mag, aber schon für RTP sehe ich da nichts mehr.
Das ist dann beim AVM-QoS (NQoS) schon wieder etwas mehr und näher an dem, was man von den DSL-Boxen kennt (nur als Auszug, die Definitionen der Queues stehen entweder an anderer Stelle in den Supportdaten oder im procFS oder in der "ar7.cfg", je nachdem, wo man selbst lieber suchen will):
Ich habe selbst dort nichts weiter eingerichtet, würde aber die Behauptung aufstellen wollen, daß die Einstellungen im GUI genau hier ansetzen und nicht beim DOCSIS-QoS und somit wird hier eigentlich nur geregelt, was zuerst vom eRouter an das eCM übergeben wird, während dieses dann selbst noch einmal klassifiziert und entsprechend priorisiert.
Das ist auch der Grund, warum ich in #13 davon schrieb, daß es ja durchaus auch der PIE-AQM-Algorithmus sein könnte (Proportional Integral Enhanced Active Queue Management), der zumindest für die auftretenden Packet-Drops verantwortlich ist. Wenn das so wäre, müßten m.E. auch die AVM-Boxen davon betroffen sein, weil diese Entscheidungen eben im eCM-Teil getroffen werden (MULPI, Anhang M) und der sollte von Intel stammen.
Mit der Verzögerung meinte ich auch mehr die bisher schon entstandene ... die erste Ankündigung erfolgte ja schon 2015 zur ANGACOM und seither läßt die 6590 auf sich warten. Das ist im Vergleich zu (auch später angekündigten) DSL-Modellen schon recht lange und so kann man eben spekulieren, was die Ursache der Verzögerung am Ende war.
Die anderen Änderungen in der 6590 (MU-MIMO in erster Linie) haben ja bei DSL-Modellen bereits Einzug gehalten - wobei natürlich auch hier mit den Hotspot-Funktionen (sicherlich über WIFI-GW realisiert bei VF und UM?) noch eine Besonderheit bei den DOCSIS-Modellen lauern könnte; aber das ist bei der 6490 auch schon so und das Tunneln spielt sich ja eher auf höheren Layern ab und sollte von den verwendeten WLAN-Chipsets unabhängig sein (mithin auch davon, ob das nun das "alte AC" mit einem Stream ist oder 4x4 mit MU-MIMO). Anders als bei der 7590 (aber das ist ein anderes Thema und ich lasse mich nur zu gerne eines Besseren belehren von AVM) glaube ich bei der 6590 jedoch tatsächlich daran, daß die um die ANGACOM herum in den Einzelhandel kommen könnte.
Die ersten auftauchenden Boxen in der Provisionierung würde ich eher bei AVM selbst bzw. den dortigen Mitarbeitern (auch daheim) "verorten" ... oder meintest Du wirklich, daß bereits KNB die 6590 selbst in ihren eigenen Netzen (in nennenswertem Umfang) durch Kunden oder meinetwegen eigene Mitarbeiter (außerhalb der Labore) testen lassen? An solchen Stellen staune ich immer wieder aufs Neue, wieso sich so etwas dann nicht herumspricht (nicht mal "andeutungsweise") - allen NDA oder ähnlichen Konstruktionen zum Trotz.
Das geht vom Mail-Admin bei einem Provider, wo ein Push-Service so einer Box eine entsprechende E-Mail hinterläßt (die ist m.W. immer noch unverschlüsselt) bis zum SIP-Server bei einem (externen) Anbieter, wo der User-Agent-Header dann in aller Regel nähere Informationen zum Modell enthält - da existieren so viele "Schwachstellen", die auch keinem NDA unterliegen und wo der Datenschutz schon sehr genau genommen werden müßte, wenn das nicht (notfalls anonym) nach außen dringt (logischerweise ohne Details), daß ich wirklich staune. Das heißt nicht, daß ich das schlecht finde ... es ist/wäre nur ungewöhnlich nach meinen eigenen Erfahrungen, auf welchen verschlungenen Wegen die Leute an solche Informationen gelangen. Dagegen sind die bekannten Fotographen für die "Erlkönige" in der Automobil-Industrie ja fast Waisenknaben, wenn es um "Findigkeit" einiger bei der Suche nach solchen Indizien im Netz geht.
@fesc:
Es hat sicherlich auch der Provider seinen Anteil an solchen Ergebnissen, wenn das Segment überlastet ist und es häufiger zu "congestion" am CMTS kommt.
Ich würde hier ohnehin (erneut ohne es zu wissen, nur rein aus "Überlegungen" und auf der Basis von Beobachtungen in den Supportdaten) annehmen, daß da zwei unabhängige QoS-Lösungen (hoffentlich) miteinander arbeiten. Das DOCSIS-QoS (vom Provider konfiguriert) sieht bei mir so aus (VF/KD 100/6):
Code:
DOCSIS QOS
----------
Active Downstream Service Flows:
--------------------------------
* Service Flow -1 (SFID 285dd3) Primary
Schedule Type: Undefined
MaxTrafficRate 106000000, MaxTrafficBurst 3044, MinReservedRate 0
MaxConcatBurst 1522, MinReservedPkt 0
* Service Flow -1 (SFID 285dd5)
Schedule Type: Undefined
MaxTrafficRate 0, MaxTrafficBurst 3044, MinReservedRate 0
MaxConcatBurst 1522, MinReservedPkt 0
Priority 4
Active Upstream Service Flows:
--------------------------------
* Service Flow 0 (SFID 285dd2) Primary
created 8463 active 50209295
Schedule Type: Best Effort
MaxTrafficRate 6360000, MaxTrafficBurst 28000, MinReservedRate 0
MaxConcatBurst 28000, MinReservedPkt 0
TosAndMask 0x0, TosOrMask 0x0
Pkts 4199763 Bytes 543695200 PolicedDropPkts 0 Delayed 0 UnknownPHS 0
* Service Flow 1 (SFID 285dd4)
created 8464 active 50209295
Schedule Type: Best Effort
MaxTrafficRate 0, MaxTrafficBurst 3044, MinReservedRate 0
MaxConcatBurst 1522, MinReservedPkt 0
Priority 4
TosAndMask 0x68, TosOrMask 0x68
Pkts 466 Bytes 454176 PolicedDropPkts 0 Delayed 0 UnknownPHS 0
Classifiers:
-----------------------
Clfy 0: EtherType MAC ==> SF 285dd4
Clfy 1: IPv4 DST 88.134.123.0/255.255.255.0 Proto 17 Ports 0:5060 ==> SF 285dd4
Clfy 2: IPv4 DST 88.134.123.0/255.255.255.0 Proto 17 TosLow 0x50 TosHigh 0x50 Mask 0xff ==> SF 285dd4
Clfy 3: EtherType MAC ==> SF 285dd4
Clfy 4: IPv4 SRC 10.0.0.0/255.0.0.0 Proto 17 Ports 0:67 ==> SF 285dd4
Clfy 5: IPv6 SRC 2a02:8101:1000::/36 DST 2a02:8100::/32 Proto 17 Ports 0:53 ==> SF 285dd4
Clfy 6: IPv6 SRC 2a02:8101:1000::/36 DST 2a02:8100::/32 Proto 17 Ports 0:547 ==> SF 285dd4
Clfy 7: IPv4 DST 10.0.0.0/255.0.0.0 Proto 17 Ports 0:161 ==> SF 285dd5
Clfy 8: IPv4 SRC 88.134.123.0/255.255.255.0 Proto 17 Ports 5060:0 ==> SF 285dd5
Clfy 9: IPv4 DST 10.0.0.0/255.0.0.0 Proto 17 Ports 67:0 ==> SF 285dd5
Clfy 10: IPv6 SRC 2a02:8100::/32 DST 2a02:8101:1000::/36 Proto 17 Ports 53:0 ==> SF 285dd5
Clfy 11: IPv6 SRC 2a02:8100::/32 DST 2a02:8101:1000::/36 Proto 17 Ports 547:0 ==> SF 285dd5Das ist dann beim AVM-QoS (NQoS) schon wieder etwas mehr und näher an dem, was man von den DSL-Boxen kennt (nur als Auszug, die Definitionen der Queues stehen entweder an anderer Stelle in den Supportdaten oder im procFS oder in der "ar7.cfg", je nachdem, wo man selbst lieber suchen will):
Code:
##### BEGIN SECTION nqos nqos
appls:
0: sip (1) => 1
early_recvhook:
enabled
erouter0 ethervcc_fastrcv(472f725c)
lan:
0: ip.proto 17 udp.dport 43962,47806 => 2
0: ip.proto 58 => 2
0: ip.proto 1 => 2
0: ip.proto 17 => 2
1: udp.dport 53 => 2
1: udp.dport 5060 (sip) => 5
0: ip.proto 6 tcp.dport 5060 (sip) => 5
local:
0: localmark sip => 1
0: localmark rtp => 1
0: localmark sip_internet => 1
0: localmark rtp_internet => 1
0: localmark sipdns,ntpdns,tr069dns,tr069 => 2
0: localmark igmp => 3
0: localmark webdav => 4
0: localmark dns => 2
results:
0: queue 5
1: queue 2
2: queue 1
3: queue 0
4: queue 6
5: queue 2 appl sip
##### END SECTION nqos nqosDas ist auch der Grund, warum ich in #13 davon schrieb, daß es ja durchaus auch der PIE-AQM-Algorithmus sein könnte (Proportional Integral Enhanced Active Queue Management), der zumindest für die auftretenden Packet-Drops verantwortlich ist. Wenn das so wäre, müßten m.E. auch die AVM-Boxen davon betroffen sein, weil diese Entscheidungen eben im eCM-Teil getroffen werden (MULPI, Anhang M) und der sollte von Intel stammen.
