Beiträge von pufferueberlauf

Zitat von BlackMage2

wieso ist das für den Massenmarkt tot?

Weil das kein Massenmarkt-ISP anbietet... alle aktuell neuen Roll-Outs betreffen GPON, XGSPON, und Tests mit 25G und 50G-PON... mein Verdacht ist, zu teuer... ist ja oefter so, dass sich erst langsam herauskristallisiert welche Loesung der Massenmarkt annimmt, und das muss nicht immer die technisch ueberlegene Loesung sein.

Zitat von BlackMage2

NG-PON2 ist doch optimal für den Glasfasermarkt. Es kann 10/2.5 Gbps, 10/10 Gbps und 2.5/1.25 Gbps(brutto), sowie natürlich auch alles darunter.

aber ich sehe schon wo das Problem liegt: die geringen Buchungsraten, besonders von den höheren Tarifen.

Ja, aber das kann, zumindest nominell XGS-PON auch... aber XGSPON wird von den grossen Ausruestern relativ guenstig angeboten und die OLT-Chassis erlauben oft Kombo-Ports die sowohl G, als auch XGS-PON erlauben, gleichzeitig. Ich habe solche Angebote jetzt fuer GPON plus BG-PON2 noch nicht gesehen... Wie gesagt, im Massenmarkt gewinnt nicht immer die technisch beste Loesung...

Zitat von Phino

Da nehmen sie eindeutig die billigste und einfachste Technik. Vielleicht in 10, 20, 30 Jahre.

Auch dann nicht... NG-PON2 ist tot...

NG-PON2 ist IMHO fuer den Massenmarkt tot.... daher ist eher irrelevant welche theoretischen Kombinationen damit moeglich waeren.

Mein Verdacht ist, weil das ein Feld fuer eine Rate ist, aber beim BiDi Test zwei Raten anfallen... Dazu kommt, dass die BiDi Raten ca. 2.5% geringer ausfallen duerften als die unidirektionalen Raten, weil beim BiDi Test halt auch immer der reverse ACK Traffic gegen die Lastrichtung anfaellt und der liegt bei TCP-Reno bei ca. 2.5% der Vorwaertsdatenrate.
Die Datenraten stehen bei diesem Test ganz klar nicht im Vordergrund... dafuer versucht er aber auch nicht die ueblichen absurden zeitaufgeloesten maximal-Raten zu zeigen. Die liegen bei vielen On-line Tests oft ueber dem technisch tatsaechlich Moeglichen... (IMHO ein Artefakt davon wie TCP/QUIC mit Retransmissionen umgehen).

Aber ich kann ja mal fragen, ob die Entwickler Lust haben, die BiDi Raten mit anzugeben?

Die Felder Download/Upload reportieren, wenn ich mich recht erinnere die mittlere Datenrate fuer die jeweilige Epoche.

Hier mal von O2 (PoP in/um HH):

user@computer hostap % trip --mode pretty -C 100 -4 bbm5-ias.breitbandmessung.de -u
┌─────┬────────────────┬──────────────────────────────────────────────────────┬───────┬─────┬──────┬──────┬──────┬──────┬──────┬────────┐
│ Hop ┆ IPs            ┆ Addrs                                                ┆ Loss% ┆ Snt ┆ Recv ┆ Last ┆ Avg  ┆ Best ┆ Wrst ┆ StdDev │
╞═════╪════════════════╪══════════════════════════════════════════════════════╪═══════╪═════╪══════╪══════╪══════╪══════╪══════╪════════╡
│ 1   ┆ 192.168.42.1   ┆ 192.168.42.1                                         ┆ 0.0   ┆ 100 ┆ 100  ┆ 0.6  ┆ 0.8  ┆ 0.6  ┆ 1.2  ┆ 0.1    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 2   ┆ 62.52.192.240  ┆ loopback1.0001.acln.01.ahr.de.net.telefonica.de      ┆ 0.0   ┆ 100 ┆ 100  ┆ 10.9 ┆ 11.1 ┆ 10.1 ┆ 20.9 ┆ 1.4    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 3   ┆ 62.53.11.234   ┆ bundle-ether4.0002.cord.01.ahr.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 12.0 ┆ 11.1 ┆ 10.0 ┆ 21.1 ┆ 1.1    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 4   ┆ 62.53.3.36     ┆ bundle-ether21.0003.corx.01.ham.de.net.telefonica.de ┆ 0.0   ┆ 100 ┆ 100  ┆ 17.6 ┆ 18.5 ┆ 17.1 ┆ 20.2 ┆ 0.6    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 5   ┆ 62.53.0.35     ┆ bundle-ether7.0002.corx.01.off.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 17.6 ┆ 18.8 ┆ 17.4 ┆ 24.0 ┆ 0.9    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 6   ┆ 62.53.4.3      ┆ bundle-ether3.0002.cord.01.off.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 18.2 ┆ 18.1 ┆ 17.3 ┆ 20.1 ┆ 0.5    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 7   ┆ 62.53.28.179   ┆ bundle-ether2.0002.corp.01.off.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 18.4 ┆ 18.5 ┆ 17.4 ┆ 30.3 ┆ 1.1    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 8   ┆ 80.81.197.31   ┆ ipv4.de-cix.fra.de.as211319.breitbandmessung.de      ┆ 0.0   ┆ 100 ┆ 100  ┆ 17.7 ┆ 19.0 ┆ 17.0 ┆ 35.3 ┆ 3.3    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 9   ┆ 193.238.173.22 ┆ 193.238.173.22                                       ┆ 0.0   ┆ 100 ┆ 100  ┆ 18.3 ┆ 17.8 ┆ 16.8 ┆ 19.8 ┆ 0.4    │
└─────┴────────────────┴──────────────────────────────────────────────────────┴───────┴─────┴──────┴──────┴──────┴──────┴──────┴────────┘

und via IPv6:

user@computer hostap % trip --mode pretty -C 100 -6 bbm5-ias.breitbandmessung.de -u
┌─────┬────────────────────────┬────────────────────────────────────────────────────────────────────────┬───────┬─────┬──────┬──────┬──────┬──────┬──────┬────────┐
│ Hop ┆ IPs                    ┆ Addrs                                                                  ┆ Loss% ┆ Snt ┆ Recv ┆ Last ┆ Avg  ┆ Best ┆ Wrst ┆ StdDev │
╞═════╪════════════════════════╪════════════════════════════════════════════════════════════════════════╪═══════╪═════╪══════╪══════╪══════╪══════╪══════╪════════╡
│ 1   ┆ 2a02:3100:88e6:5e00::1 ┆ dynamic-2a02-3100-88e6-5e00-0000-0000-0000-0001.310.pool.telefonica.de ┆ 0.0   ┆ 100 ┆ 100  ┆ 0.8  ┆ 0.7  ┆ 0.5  ┆ 2.6  ┆ 0.2    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 2   ┆ 2a02:3001::20a         ┆ 2a02:3001::20a                                                         ┆ 0.0   ┆ 100 ┆ 100  ┆ 13.2 ┆ 10.9 ┆ 9.4  ┆ 21.9 ┆ 1.3    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 3   ┆ 2001:7f8::1a95:0:2     ┆ 80.81.193.89xp.decix.fra.de.net.telefonica.de                          ┆ 66.0  ┆ 100 ┆ 34   ┆ 18.6 ┆ 19.1 ┆ 17.8 ┆ 22.5 ┆ 1.0    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 4   ┆ 2001:7f8::3:3977:0:1   ┆ ipv6.de-cix.fra.de.as211319.breitbandmessung.de                        ┆ 0.0   ┆ 100 ┆ 100  ┆ 17.5 ┆ 17.8 ┆ 16.3 ┆ 34.1 ┆ 2.5    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 5   ┆ 2a11:380:1::5:3        ┆ 2a11:380:1::5:3                                                        ┆ 0.0   ┆ 100 ┆ 100  ┆ 17.4 ┆ 17.6 ┆ 16.7 ┆ 21.9 ┆ 0.6    │
└─────┴────────────────────────┴────────────────────────────────────────────────────────────────────────┴───────┴─────┴──────┴──────┴──────┴──────┴──────┴────────┘

Das ist vorsaetzlich die Web-Adresse und nicht die IP-Adresse einer der Messserver... weil unklar ist ob/wie die auf Pings reagieren und wie stabil deren IP Adressen sind. Und ja die Web-Adresse wird wohl in/um Muenchen gehostet, d.h. kleine RTTs wahrscheinlich am ehesten von M-Net Kunden aus dem Grossraum Muenchen..

AON ist weit weniger waehlerisch, da solllte jeder Medienkonverter mit dem passenden SFP Modul funktionieren... da das Fritz-AON Modul vom Typ: 1000BASE-BX10 ist sollten auch andere Module dieses Typs funktionieren.

SpeedOf.Me ist meiner Erfahrung nach einer der exotischeren Kapazitaetstests, ich wuerde empfehlen da erstmal mit den ueblichen Verdaechtigen anzufangen:

breitbandmessung.de

speedtest.net

speed.cloudflare.com

bufferbloat.libreqos.com

Zitat von Schwiegersohn38

SpeedOf.Me meldet (mittels direkt am LAN des Router angehängten Rechners) einen Datendurchsatz von ca. 120..150 Mbps im Download und Werte um 200 Mbps im Upload. Ihr selbst ist der langsamere Aufbau von Internetseiten auf ihrem Laptop auch schon aufgefallen, ich habe leider keine Vergleichswerte vom Zeitpunkt vor der Umstellung.

Das Problem duerfte nicht der Durchsatz sein, ob 100 oder 400 Mbps macht bei normalem Internetbrowsing keinen spuerbaren Unterschied. D.h. gut moeglich, dass der DG Internetzugang schlechter ist, als das was sie vorher hatte, aber die Ursache duerfte eher nicht mit dem SpeedOf.Me Ergebnis zusammenhaengen.

Hast Du zufaelligerweise ein Linux zur Hand? Dann waeren ein Paar tracepath Tests aufschlussreich:

tracepath -b -4 one.one.one.one
tracepath -b -6 one.one.one.one

Tracepath laeuft mit normalen Userrechten und repotiert unter anderen die Pfad-MTU.

Das sieht dann z.B. so aus:

smoeller@RPi4BGPSNTP:~ $ tracepath -b -4 one.one.one.one
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.42.1 (192.168.42.1)                           0.443ms 
 1:  192.168.42.1 (192.168.42.1)                           0.545ms 
 2:  192.168.42.1 (192.168.42.1)                           0.534ms pmtu 1492
 2:  loopback1.0006.acln.01.ham.de.net.telefonica.de (62.52.192.120)  12.126ms 
 3:  bundle-ether17.0002.cord.01.ham.de.net.telefonica.de (62.53.11.182)  10.538ms 
 4:  ae0-0.0002.corp.01.ham.de.net.telefonica.de (62.53.12.89)  10.034ms 
 5:  as13335.hamburg.megaport.com (193.42.155.58)         18.349ms 
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply

Der Host in meinem LAN kann da erfolgreich mit MTU 1500 arbeiten und zeigt das auch an, ab dem PPPoE-Router geht es dann aus Sicht des Endhosts mit MTU 1492 weiter... Da Endpunkte oft gar nicht auf die Tracepath Probes antworten, ist das Ende oft eine etwas unelegante lange liste von no reply Hops, aber das kann man hier ignorieren. Fuer Deinen Anschluss waere es interessant zu wissen welche pmtu im LAN ab Deinem Router und nach dem AFTR verwendet wird und zwar getrennt fuer IPv4 und IPv6...

Alternativ kann man das auch per Hand mit ping machen, Anleitung z.B.: hier

Das mit der Fragmentierung ist dann das Problem des ISPs, ist der zu braesig Jumboframes zu konfigurieren ist das IMHO sein selbstgewaehltes Schicksal. Aehnliches gilt uebrigens auch fuer PPPoE (rfc4638)... hat die Telekom wohl mal angedacht, aber dann wieder fallen gelassen.

Und was den Rest angeht, bleibe ich bei lieber messen als nur anzunehmen...

Ich wiederhole meine Empfehlung, Messen statt annehmen. MTU ist Ethernet Nutzlast und es ist diskutierbar ob das nicht von der L3 IP Layer selber behandelt werden sollte, statt von L4, aber die Trennung von L3 und L4 ist mehr historisch gewachsen als sinnvoll designed.

Die IETF schlaegt fuer DS lite vor (rfc6333), dass ISPs den IPv6 Tunnel mit Baby Jumboframes so konfigurieren, dass die IPv6 Nutzlast fuer getunneltes IPv4 1500 Bytes gross ist, alternative muss der ISP defragmentieren:

5.3.  Fragmentation and Reassembly

   Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
   traffic over IPv6 will reduce the effective MTU of the datagram.
   Unfortunately, path MTU discovery [RFC1191] is not a reliable method
   to deal with this problem.

   A solution to deal with this problem is for the service provider to
   increase the MTU size of all the links between the B4 element and the
   AFTR elements by at least 40 bytes to accommodate both the IPv6
   encapsulation header and the IPv4 datagram without fragmenting the
   IPv6 packet.

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv6 packet.  Reassembly MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2.

Wuerde da nicht auf den ISP vertrauen, sondern das selber nachmessen.

Und Achtung, wennman z.B. PPPoE auth eth0 betreibt, sollte die MTU fuer das pppoe Interface meist in der Tat bei 1492 liegen, aber die MTU fuer eth0 muss bei 1500 bleiben, weil der pppoe header innerhalb der eth0 MTU "lebt".

Das sieht ziemlich gut bis optimal aus, gerade auch fuer 116 Tage Sync.

Die Channel Charanteristic Kurve sieht ueber 17 MHz etwas holprig aus, aber das ist ein Luxusproblem (und ich habe noch nicht viele dieser Kurven fier Profil 35b Anschluesse gesehen, vielleicht ist das ganz normal).

Ich vermute der DSL-Link wird ganz geschmeidig funktionieren, und fuer die meisten ueblichen interaktiven Nutzungen duerfte sich nominelle 250/40 (tatsaechlich brutto 292.023/46.719 und netto 269.6/43.1) aehnlich anfuehlen wie die 600/300 der DGN.

IPv4:
292.023 * 64/65 * ((1500-8-20-20)/(1500-8+35)) = 273.4 Mbps
46.719 * 64/65 * ((1500-8-20-20)/(1500-8+35)) = 43.7 Mbps
IPv6:
292.023 * 64/65 * ((1500-8-40-20)/(1500-8+35)) = 269.6 Mbps
46.719 * 64/65 * ((1500-8-40-20)/(1500-8+35)) = 43.1 Mbps

Ah, besten Dank. Weder im Up- noch im Download erreicht Dein Link Vollsync (fuer den 250er waere das 292,032/46,720 Mbps) aber nahe dran... aufgrund der (geschaetzten) DSL performaqnce capacity, sollte Vollsync eigentlich moeglich sein. Aber das mag der Unterschjied zwischen Theorie und Praxis sein.

Jetzt waere es toll wenn wir SNR/Bitloading/QLN/und Hlog Spektren sehen koennen, da kann man oft erkennen warum es nicht zu Vollsync kommt.

Da der VMG3006 rein Lantiq-SoC zu nutzen scheint, versuch doch mal Dein Glueck mit go-dsl, das sieht dann in etwa so aus:

Go-dsl zeigt Minimum und Maximum immer nur ueber die Zeit an die die GUI offen war, daher macht es Sinn die GUI etwas laufen zu lassen bevor man den Screenshot macht. Ich checke immer beide Checkboxen, also "Show minimum/maximum" und "Auto-scale graphs", weil beides IMHO fuer die Bewertung eines Links hilfreich ist.

Zitat von __QT__

Die Zukunft wird zeigen, wie es weitergeht. Der Plan ist aber erstmal, auf SVDSL zu gehen und das auszuprobieren.

Hast Du da eine Fritzbox dran haengen? Wenn ja, dann mach doch mal Screenshots von allen Tabs im Bereich Internet -> DSL-Informationen (beim Spektrum-Tab, bitte erst die Checkbox "Minima und Maxima anzeigen" unten anklicken). Das ganze am besten in einem neuen Thread

Achtung, die Dokumentation ist generell OK, hat aber ein paar Punkte mit Luft nach oben.

Interval / Target: interval und target sind nicht unabhaengig von einander, fuer optimale network power (in etwa Durchsatz/Latenz) sollte target im Bereich 5-10% von interval gewaehlt werden.

Limit: der Grund fuer die Emphehlung Limit auf 1000 zu setzen war, dass bei der Verwendung billiger All in One Router meist nicht genug RAM vorhanden ist um 10240 Pakete zu queuen ohne den OOM Killer auf den Plan zu rufen. Das ist bei Opensense auf x86 mit hoher Wahrscheinlichkeit kein relevanter Punkt mehr. Unter Linux wurde das Problem durch den zusaetzlichen Parameter memory_limit behoben, der den tatsaechlichen Speicherbedarf limitiert.

Was komplett zu fehlen scheint ist die Moeglichkeit den Per-Paket-Overhead zu spezifizieren (sowie MPU und eventuell ATM Verkaoselung, wobei das letztere zunehmend irrelevant wird).

Klar gegen "kostenlos" ist schwer anzukommen. Und wenn man nicht bemerkt vom vorsaetzlichen Unterpeering betroffen zu sein*, ist die Telekom ja auch ein kompetenter ISP, mit ein paar attraktiven Eigenschaften (bezueglich Endgeraetefreiheit, DualStack und PPPoE Reconnects).

*) Ich gehe davon, aus, dass fast alle Nutzer davon betroffen sind, es aber nur wenigen tatsaechlich auffaellt.

Zitat von frank_m

es gibt einen Grund, warum hier so häufig im Forum steht: Den Traffic Shaper immer auf die realen Werte des Anschlusses stellen.

Dabei ist es so, dass due Vertragsraten inzwischen fast immer als Netto-Raten spezifiziert werden, waehrend Traffic-Shaper mit Brutto-Raten konfiguriert werden muessen (plus Per-Paket-Overheadwerten). Dazu kommt, dass AVM zumindest in der Vergangenheit die eingegebenen Werte nicht Eins zu Eins uebernommen hat, sondern bei zu grossen Abweichungen von den vom ISP uebermittelten Raten, statt dessen die ISP Raten verwendet hat (und nein, das war IMHO nur bedingt eine gute Idee, besser waere es gewesen, den Kunden bei der Eingabe stark abweichender Werte einfach auf diese Abweichung hinzuweisen).

Bei ueblicher GPON-Verkapselung (ohne PPPoE, aber mit VLAN) ist der Unterschied netto zu brutto bei maximal grossen Paketen und korrekten Overhead Settings:

IPv4: 100 - 100 * (1500 - 20 -20) / (1500+27) = 4.4%-Punkte

IPv6: 100 - 100 * (1500 - 40 -20) / (1500+27) = 5.7%-Punkte

Das ist etwas weniger als beim Download-Shaping empfehlenswert ist (eher 10-20% Abschlag, je nach dem wie robust man Latenzspitzen vermeiden moechte). und etwas mehr als beim Upload-Shaping notwendig ist. Aber das sind zumindest keine komplett ungeeigneten Startwerte fuer einen Traffic-Shaper.

Zitat von xploded76

Richtig happy wäre ich damit nicht. 355 statt 400 sind schon ein Verlust.

Mei, ich habe vor ein paar Jahren einen nominellen 100/40 Anschluss, mit Sync ca 90/30 auf 40/29 geshaped, weil mein Router damals nicht performant fuer ein hoeheres Shaper-Limit war, aber in direkten Tests war 40/29 mit SQM fuer unsere Nutzung besser als 90/30 ohne SQM. Aber das ist natuerlich subjektiv und nur weil das fuer uns besser war, heisst das nicht, dass man das nicht auch anders bewerten kann.
Der Unterschied 355 oder 400 kommt eigentlich nur dann zum Tragen, wenn man zeitkritische grosse Downloads hat, und das oft genug, dass es auffaellt wenn das ca. 10% laenger dauert....

Zitat von frank_m

Ist natürlich richtig. Nur ist dieser Zustand "unter Last" an meinem Anschluss so selten, dass es sich bislang einfach nicht gelohnt hat.

Ah, okay, aber dann sind die 10% Abschlag von der maximalen Kapazitaet auch kein Problem?

Zitat von frank_m

Was ich aber schon sagen kann, es ist eher ein Test der Router als der Provider.

Jein, ein kompetenter Festnetz-ISP hat seine Seite gut debloated, und dann ist zumindest in Downloadrichtung kaum Bufferbloat sichtbar, der Router ist dann nur fuer die Uploadrichtung zustaendig... andererseits bei dem was bei uns zu Lande ueblich ist, ist das dann schon ein Router-Test.

Zitat von frank_m

Klemme ich einen selbstgebauten Linux Router mit CAKE für beiden Richtungen hinter die Fritzbox und messe dann hinter diesem Router, dann bin ich sofort bei A+ mit 3.5 ms - allerdings bei resultierenden 360 / 180 MBit/s. Ich verliere also 10% Bandbreite in beide Richtungen. Das kann ich ein bisschen höher tunen in beide Richtungen, allerdings gibts dann schnell Latenz-Ausreißer.

"Verlieren" klingt so negativ, ich wuerde sagen mit nur 10% potentiellem Durchsatz erkaufst Du Dir recht zuverlaessig niedrige Latenz auch unter Last bzw. under normalen Arbeitsbedingungen