Beiträge von pufferueberlauf

Die DNS Server geben Dir die IP Adresse des Zielservers, und bei grossen Anbietern gibt es da haeufig Optionen, so kann dieselbe URL zu unterschiedlichen IP Adressen aufgeloest werden (ich meine Akamai macht das gerbe so, waehrend Cloudflare eher auf Anycast setzt). Und je nach Standort ist dann eine IP Adresse von einem bestimmten ISP besser zu erreichen als eine andere, und genau da kommt dann der DNS Server ins Spiel.

Zitat von Wellenreiter

Bis hierhin alles gut, in dem Moment als ich DoH (Encrypted DNS) eingeschaltet habe, gingen die Speedtests zwischen 500-700Mbit runter. Gegenprobe und wieder deaktiviert, volle 2500-2600Mbits im Download.

Fuer mich deutet das an, dass Dein ISP gute und schlechte Uebergaben hat, bei den ISP-eigenen DNS-Servern wird man ueber die guten Uebergaben geleitet, beim DoH Anbieter halt ueber weniger gute Uebergaben. Das ist IMHO im Internet nicht unueblich und daher muss man sich genau ueberlegen von wem man DNS Informationen beziehen will.

(Selber betreibe ich meinen eigenen cachenden Resolver, der nicht zu den ISP-DNS-Servern forwarded, d.h. ich befrage erst mal die root-server, aber fuer meine VoIP/SIP Basis musste ich die ISP DNS-Server hardkodieren*)

*) SIP ist bei O2 etwas ungluecklich implementiert mit einigen unnoetigen Fallstricken... der Name wird nur von den O2-eigenen DNS-Server aufgeloest und nur wenn die Anfrage auch von einer O2-IP Adresse kam und die DNSv6 Server liefern zwar Informationen, aber damit funktioniert das leider oft nicht. Weil Doppel-Flatrate und Wenig-Telephonierer (aber wenn meist ins Mobilfunknetz und das ist bei SIP Anbietern leider meist etwas teurer) habe ich die Telephonie bei O2 belassen, aber eigentlich meine ich gehoert die in die Haende von einem spezialisierten SIP-Anbieter...
IMHO sollten Doubleplay (Internet+Telephonie) und Tripleplay ((Internet+Telephonie+TV) Angebote verboten gehoeren, insbesondere Rabatte ()und auch fuer Mobil- und Festnetz aus eine Hand sollte es keine extra Rabatte geben). Also ISPs sollen gerne alles anbieten duerfen, aber halt nicht als rabattiertes Koppelpaket.

Zitat von HubeBube

Uneingeschränkt stimme ich mit dir überein, dass es keine mangelhafte oder gar fehlende Kommunikation bei Geschäftskundenanschlüssen geben darf!

Und auch bei Privatkunden kann man mit besserer Kommunikation deutlich mehr Zufriedenheit erreichen/erhalten. Egal bei welchem ISP, es geht immer mal etwas schief, aber man kann besser oder schlechter mit solchen Situationen umgehen, und Totschweigen ist klar eine sub-optimale Strategie.

Zitat von pufferueberlauf

Und hier ohne SQM:

So der LibreQoS Test ist etwas aufgebohrt worden (und die generierten PNGs sind etwas kleiner und fokussierter, so, dass man sie hier posten kann ohne sie croppen zu muessen) und zusaetzlich vom Single Test gibt es auch den "virtual household Test", der zeigt wie gut verschiedene Nutzungen von einander getrennt werden. Hier ein Beispiel von einem Link mit hoher Kapazitaet aber ohne SQM:

Die Monopolkommissiion lebt da in einer Phantasiewelt... "Wo es wirtschaftlich sinnvoll ist" laeuft auf so gut wie nirgendwo raus. Das ist neoliberaler Dogmatismus, bzw. ein Beharren auf dem inzwischen eigentlich komplett invalidierten Leitermodell zur Privatisierung, bei der es zu Infrastrukturwettbewerb kommen soll... das passiert hat i.d.R. eben nicht und schon gar nicht flaechendeckend. Das Argument gegen physische Entbuendelung ist, letztlich, "das moegen ISPs nicht gerne" und daher stellen sie vielleicht Investionen zurueck wenn man sie zum Entbuendeln zwingt... Letztlich heisst das aber halt auch nur, das genau dieses Entbuebdeln gut fuer echten Wettbewerb waere...

Wobei das alles gerundete theoretische Brutto-Zahlen sind:

Mit dem fast universell eingesetzten FEC bleibt bei GPON von brutto 2488.32/1244.16 noch

FEC RS(255,239)

2488.32 * 239/255 = 2332.19 Mbps
1244.16 * 239/255 = 1166.10 Mbps

uebrig (auch brutto und ohne OMCI Overhead)

und bei XGSPON von 9.95328/9.95328 Gbps

brutto nach FEC:
9.95328 * (216/248) = 8.66899 Gbps

Das ist weder 2.5 bei GPON, noch 10 bei XGSPON... Aber das ist dann halt die Wirklichkeit des Marketings, kein ISP gewinnt Kunden durch knechtische Korrektheit und von der Nutzbarkeit ist es eher egal was das tatsaechliche Brutto-Limit ist, zumindest wenn der ISP halbwegs kompetent agiert.

Ach auch 50 GPON kommt mit einer guten Portion in-band FEC

Zitat von HubeBube

ist das in der Leistungsbeschreibung enthaltene Minimum mit 2,3 Gbps sehr knapp auf Kante genäht.

Mit FEC und OMCI Overhead ist 2.3 knapp unter der theoretischen maximalen Nutzlastrate:

FEC RS(255,239)
2488.32 * 239/255 = 2332.19 Mbps
1244.16 * 239/255 = 1166.10 Mbps

GPON Overhead (PPPoE)
#GPON-GEM: GEM = 5 Byte
COMMON ETHERNET: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
PPPoE: 8 Byte
VLAN: 4 Byte
Summe: 5+18+8+4 = 35

GPON Netto goodput ohne OMCI Traffic IPv4/TCP ohne FEC
2488.32 * ((1500-8-20-20)/(1500-8+35)) = 2366.10388998
1244.16 * ((1500-8-20-20)/(1500-8+35)) = 1183.05194499

GPON Netto goodput ohne OMCI Traffic IPv4/TCP mit FEC
2488.32 * 239/255 * ((1500-8-20-20)/(1500-8+35)) = 2217.64246943
1244.16 * 239/255 * ((1500-8-20-20)/(1500-8+35)) = 1108.82123472

GPON Netto goodput ohne OMCI Traffic IPv6/TCP ohne FEC
2488.32 * ((1500-8-40-20)/(1500-8+35)) = 2333.51292731
1244.16 * ((1500-8-40-20)/(1500-8+35)) = 1166.75646365

GPON Netto goodput ohne OMCI Traffic IPv6/TCP mit FEC
2488.32 * 239/255 * ((1500-8-40-20)/(1500-8+35)) = 2187.09642991
1244.16 * 239/255 * ((1500-8-40-20)/(1500-8+35)) = 1093.54821495

Solange die BNetzA so etwas durchgehen laesst werden ISPs das weiterhin machen...

Na, ja, die DG koennte sich auch ehrlich machen und in Werbung und PIB des nominellen 1 Gbps Tarifs auch nur ein Maximum von 900 bzw. 940 versprechen...

Persoenlich sehe ich da Handlungsbedarf bei der BNetzA. Es ist eine Sache, dass beim Nachweis der Vertragskonformitaet nur 90% des vertraglichen Maximums erreicht werden muss, aber eine andere wenn das vertragliche Nettomaximum schlicht unmoeglich erreicht werden kann.

Bin selber nicht betroffen, sonst wuerde ich mich an die BNetzA wenden...

Der PPPoE Header ist 8 Byte. bei MTU 1500 also:

100 * 8/1500 = 0.53%

Ja ich habe da bei der Uebersichtstabelle aufgehoert zu suchen, und ganz verdraengt, dass jan das ganze schon mal geklaert hatte... werde meinen alten Post korrigieren...

Zitat von HubeBube

Verbraucherzentrale und BNetzA sind die letzte Eskalationsstufe und üblicherweise dauern Reaktionen u.U. Wochen. D.h. eine schnelle Lösung lässt sich durch eine Kontaktaufnahme selten erzielen.

Stimme ich zu, aber all zu viele Eskalationsstufen hat man nicht, und wenn man bereits ein Frist gesetzt hatte und die ignoriert wurde, wuerde ich solch einen Schritt gehen, auch wenn der akut erst mal wenig bringen wird.

Zitat von HubeBube

Eine andere Möglichkeit evtl. schnellere Möglichkeit wäre das Einbinden der Presse. So z.B. heise "Vorsicht Kunde" oder "teltarif hilft", gerade letzteres Medienunternehmen hat schon einigen DG Kunden weitergeholfen.

+1; hatte ich vergessen. Guter Vorschlag mit dem Potential schneller zu einer Verbesserung (zumindest der Kommunikation) zu fuehren.

Zitat von Auraka

Diese endete am 5.12. Bisher ohne jegliche Rückmeldung.

Dann wuerde ich ins Auge fassen mich an die lokale Verbraucherzentrale und die BNetzA zu wenden. Wobei ich wahrscheinlich noch diese Woche abwarten wuerde, aber dann stehen die naechsten Schritte an.

Mein Verdacht ist nach wie vor, dass der Uploadtest nur mit relativ kleiner Dateigroesse durchgefuehrt wird und da reicht es halt oft nicht dazu die volle Geschwindigkeit zu erreichen... das macht auch im Rahmen des Tests Sinn, die Uploadrichtung nimmt immer den selben Pfad, nur in Downloadrichtung werden unterschiedliche "Zwischennetze" benutzt, daher duerfte das Interesse von Netzbremse und Cloudflare primaer auf der Downloadrichtung liegen.

Mmmh. WiFi hat OFDMA mitgebracht, IMHO ein massiver Unterschied zu WiFi5 der auch ohne 6GHz Band sinnvoll ist, wenn man absehen kann ausreichend viele WiFi6 Stationen zu betreiben. Die 160MHz sind IMHO eher ein Gimmick weil wegen DFS im 5GHz Band problematisch.

Guckst Du hier:

Zitat von Konrad

Wo könnte man sowas buchen oder sich dazu informieren?

Gab hier im Forum Berichte zu:

Beitrag

RE: Kaufberatung für Umstieg auf Glasfaser (DG): FRITZ!Box 5690 Pro oder FRITZ!Box 5590 Fiber?

Bei uns hat die DG mit XGS-PON ausgebaut, obwohl sie zuerst ein GPON ONT an die Wand geschraubt hat. Da das XGS-PON Modul den Fritzboxen nicht beiliegt, wird's nochmals teurer und einfach das kostenlose bereitgestellte ONT der DG zusammen mit der DSL-Fritzbox war bei uns eine gute Option.

tobix

22. März 2025 um 21:12

Beitrag

RE: Deutsche Glasfaser XGS-PON Ab April 2024

[…]

Ich habe XGS-PON von DG in freier Wildbahn gesehen. Von den Gehäusen her sind es mit an Sicherheit grenzender Wahrscheinlichkeit XGS-PON-ONTs - trotz kleiner Tarife. Die Netze wurden erst in diesem Jahr in Betrieb genommen, im mittleren und östlichen Kreis Neuwied.

Und ja, die 1577 nm liegen an:

RE: FRITZ!Box 5690 Pro: Alle Fragen/Probleme/Tipps/Hilfestellungen hierzu bitte hier eintragen!

xrandr

22. November 2025 um 00:12

Gibt es da wo die DG es verbaut (mein Verdacht waere in mit Foerderung gebauten Gebieten).

Zitat von Konrad

Gehe davon aus, dass mit XGS-GPON 8G effektiv möglich sind, deutlich unter den 10G.

Also bei der DG gibt es da noch keine entsprechenden Tarife jenseits von 1000/500 zu. Was XGSPON allgemein angeht habe ich folgende Zahlen parat:

XGS-PON
T-REC-G.9807.1-201606-I!!PDF-E.pdf
B.9.2.1 Line rate
The transmission line rate is a multiple of 8 kHz. The target standardized XGS-PON system supports
the following variant: XGS-PON with a downstream line rate of 9.95328 Gbit/s and an upstream line
rate of 9.95328 Gbit/s.
C.10.1.3.1 Downstream FEC
C.10.1.3.1.1 Downstream FEC codeword
For 9.95328 Gbit/s nominal line rate, the downstream FEC code is RS(248, 216). Each downstream
PHY frame contains 627 FEC codewords. Each codeword is 248 bytes long. Within a codeword, 216
data bytes are followed by 32 parity bytes.
C.10.1.3.2 Upstream FEC
C.10.1.3.2.1 Upstream FEC codeword
For 9.95328 Gbit/s, the upstream FEC code is RS(248, 216). The PSBu section is not included in the
FEC codeword. The first codeword in a PHY burst begins with the upstream FS header section. All
allocations of a particular ONU have the same FEC status. Contiguous allocations are encoded as a
single block of data, so that there is at most one shortened codeword at the end of the burst. For
9.95328 Gbit/s, the upstream FEC parity bytes insertion and payload reconstruction are shown in
Figures C.10.13 and C.10.14, respectively.
brutto nach FEC:
9.95328 * (216/248) = 8.66899 Gbps

XGSPON Overhead (PPPoE)
#XGSPON-XGEM: XGEM = 8 Byte
COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
PPPoE: 8 Byte
8+18+8 = 34
maximaler VLAN+PPPoE+IPv4+TCP Durchsatz ohne OMCI Traffic:
9.95328 * (216/248) * ((1500-8-20-20) / (1500-8+34)) = 8.24860248425

Also ja netto ist mehr als ca. 8 Gbps nicht drin, weil man in einem geteilten Segment eher nicht 100% der Kapazitaet an einen Anschluss liefern sollte (zumindest mit den hiesigen Transparenzregeln).

Aber Hand auf's Herz, ob 10 oder 8 Gbps duerfte fuer die ueblichen Heimnutzungen exakt gar keinen Unterschied machen, oder?

Haengt vom ISP ab und vom gebuchten Tarif, bei der DG ist auch bei XGSPON bei 1000/500 Schluss, und bei der Telekom bei 2000/1000 da braucht es auch im Heimnetz auch keine 10 Gbps Technik, 2G5BASE-T reicht aus....

Wuerde ich so machen, ich wuerde vermeiden beim ISP einen Router zu mieten, und auch bei ONTs wird das auf die Dauer teurer als selber kaufen. Gibt gerade bei Heise einen Artikel, aber weil c't Artikel hinter der Paywall:

zu genau dieser Frage.

Frage: was passiert wenn man im zu testenden neuen Router erst die MAC Adresse des bereits provisionierten Routers fuer das WAN Interface kloniert und den neuen Router erst dann mit dem ONT verbindet?

Zitat von NDiGF

Die 7530 (AArch32 QuadCore) hat eben mehr CPU-Leistung

Jetzt mag der eine oder andere die Nase ruempfen, und "nur 32bit?" denken, aber die out-of-order Arm Cortex A9 Kerne aus der Performance-Linie von Arm waren eines von Arms besseren Designs... die in-order 64bit Arm A53 Kerne die oft in Nachfolgeroutern verwendet werden verbrauchen zwar etwas weniger Strom erreichen aber die Leitung der A9 Kerne nur unter optimalen Bedingungen... (d.h. in der Praxis sind die robusteren A9 Kerne oft zuverlaessiger und schneller als A53).

Das ist letztlich OK, A53 kommen aus der Stromsparlinie, sind aber blöoederweise vermarktet worden als waeren sie gleichwertig mit A9 Kernen...

EDIT: 7530/20 haben KEINE A9 Kerne, sondern A7... mein Fehler und das ist auch keine out-of-order CPU sondern letztlich ein Vorgaenger des A53.... d.h. was oben steht ist nicht ganz falsch, aber da 7520/30 keine A9 Kerne haben ist es in diesem Thread komplett unpassend...