Glasfaser Latenzen in Glasfaser-Netzen

kingpin42 · 6. April 2023

Holzkopf schrieb:
Wenn es quatsch ist, wo kommen dann die extra 4ms her ?
Alle GPON Anschlüsse der Anbieter die hohe Splits fahren haben 3-5ms zum 1st HOP , hab da noch nie ein gesehen der im Bereich 1ms liegt.
2-3ms habe ich bei den Telekom Anschlüssen gesehen, die fahren aber halt auch kleineren Split.
nur AON hab ich bisher im Bereich 1ms gesehen.

Wo solls den herkommen wenn nicht vom PON ?

Das hat nix mit dem Split zu tun, wir haben im Testlab 1:128 Splits, trotzdem erhöht sich keine Latenz dadurch. Die höhere RTT kann von vielen Dingen kommen.

Holzkopf · 6. April 2023

nichtfrank schrieb:
1 <1 ms <1 ms <1 ms fritz.box [2a00:e180:15b8:cb00:9a9b:cbff:fec7:d79c]
2 14 ms 13 ms 13 ms dsdf1-cr3-la1-8.net.vitroconnect.de [2a00:e180:fffe:37::1]
3 21 ms 16 ms 16 ms 2a00:e180:fffe:43::1
4 17 ms 16 ms 16 ms decix.bb02.net.23m.com [2001:7f8::b957:0:1]
5 18 ms 17 ms 17 ms ae2-0.gw01.fra01.net.23m.com [2a00:f48:100:0:8000::34]
6 21 ms 16 ms 16 ms www.computerbase.de [2a00:f48:2000:1::137]

Hier kann man schön sehen das die hohe Latenz zum Gateway in düsseldorf entsteht.
zwischen dus und ffm Hop 2 zu 3 sind es die erwarteten ~3ms die auf die strecke zurückzuführern sind.

Hier mal von Stuttgart nach düsseldorf

Code:

 2  stu-nwz-dc1-te0-0-0-13.belwue.net (2001:7c0:3:c5c::) [AS553]  0.820 ms
 3  *
 4  fra-decix-a99-hu0-1-0-3.belwue.net (2001:7c0:2:111d::1) [*]  4.014 ms
 5  as57353.frankfurt.megaport.com (2001:7f8:8:20:0:e009:0:1) [*]  3.834 ms
 6  dsdf1-cr3-la2-3.net.vitroconnect.de (2a00:e180:fffe:43::2) [AS57353]  7.561 ms
 7  dsdf1-cr4-la1-8.net.vitroconnect.de (2a00:e180:fffe:37::2) [AS57353]  7.594 ms

sind 7.5ms

es kommt alos nochmal fast das doppelte an Latenz bei euch drauf und das wird das PON sein.

Ergänzung (6. April 2023)

kingpin42 schrieb:
Das hat nix mit dem Split zu tun, wir haben im Testlab 1:128 Splits, trotzdem erhöht sich keine Latenz dadurch. Die höhere RTT kann von vielen Dingen kommen.

auch soviel aktive ONTs dran ?

kingpin42 schrieb:
Die höhere RTT kann von vielen Dingen kommen.

Ja was den ? gibt mal beispiele wenn es so viel sein kann.
Da kommt doch nix mehr da sind Switche, Router und Faserstrecken.
Switche, Router erhöhen die Latenz nicht so außer sie buffern.
Und Faserstrecke wäre für die Distanz doppelt so hoch wie sie sein sollte.

kingpin42 · 8. April 2023

Holzkopf schrieb:
auch soviel aktive ONTs dran ?

Ja.

Holzkopf schrieb:
Ja was den ? gibt mal beispiele wenn es so viel sein kann.
Da kommt doch nix mehr da sind Switche, Router und Faserstrecken.
Switche, Router erhöhen die Latenz nicht so außer sie buffern.
Und Faserstrecke wäre für die Distanz doppelt so hoch wie sie sein sollte.

MEF-Knoten, weitere OLTs oder andere L2 Elemente.
Ein WLP von und aus Brandenburg hat ca 18ms RTT zum ersten Hop, einfach weil deren erster Hop bei uns im Saarland steht und dazwischen dutzende MEF Knoten und ca. 800km LWL liegt.

Holzkopf · 9. April 2023

kingpin42 schrieb:
Ja.

MEF-Knoten, weitere OLTs oder andere L2 Elemente.
Ein WLP von und aus Brandenburg hat ca 18ms RTT zum ersten Hop, einfach weil deren erster Hop bei uns im Saarland steht und dazwischen dutzende MEF Knoten und ca. 800km LWL liegt.

L2-L3 erzeugt aber keine Latenzen im ms sondern in niedrigen µs Bereich. OLTs kaskadiert man so wie ich es kenne die von den PoP in einem ausbaugebiet. das sind auch alles nur wenige km.
Saarland - Brandenburg sollten eher 10ms sein und nicht 18ms. 800km LWL = ~8ms Latenz
Bei einer ersatzroute Berlin-Hamburg-Amsterdam-Düsseldorf-Frankfurt komme ich auf 16,8ms
Was meinste was da alles zwischen hängt auf der Strecke...

In a typical TDM PON, the DBA process could result in an
upstream latency in the order of several milliseconds because
data transmission may take several DBA cycles to complete.

Another latency causing process for a TDM PON is the
need of a quiet window during the activation and registration
of new ONUs onto an operational TDM PON. No ONU can
transmit upstream data during this period, which can last over
a few 100 µs.

kingpin42 · 11. April 2023

Holzkopf schrieb:
L2-L3 erzeugt aber keine Latenzen im ms sondern in niedrigen µs Bereich.

Bei ~20 L2-Knoten (L3 würdest du im Traceroute sehen) kommt da schon das ein oder andere Millisekündchen zusammen, und da reden wir auch nur von Knoten, von denen wir definitiv wissen. Die Knoten der externen Carrier kennen wir nicht alle.

Holzkopf schrieb:
OLTs kaskadiert man so wie ich es kenne

Nokia MSANs kann man kaskadieren, würde mich wundern, wenn man das bei Adtran oder Huawei Geräten nicht kann.

Holzkopf schrieb:
Saarland - Brandenburg sollten eher 10ms sein und nicht 18ms. 800km LWL = ~8ms Latenz

Ich zitiere mal aus RFC 1925:

[...]4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.[...]

Holzkopf schrieb:
Bei einer ersatzroute Berlin-Hamburg-Amsterdam-Düsseldorf-Frankfurt komme ich auf 16,8ms
Was meinste was da alles zwischen hängt auf der Strecke...

Wenns vom selben Anbieter ist, vermutlich nicht so viel, wie wenn man auf 2 oder mehr externe Carrier angewiesen ist. Wir reden hier noch nicht einmal von der Anmietung von Darkfiber-Kapazitäten oder Alienwellenlängen, das wird dort auch oft nur als weitere E-Line geschaltet, mit der entsprechenden Kapazität.

Holzkopf · 11. April 2023

in 18ms bin ich von Frankfurt - Tschechien - Budapest - Belgrad
in 19ms Frankfurt -Amsterdam - London - Dublin
in 19ms Frankfurt - Zürich - Milan - Rom

Wer 18ms vom Saarland nach Brandenburg als In Ordnung erachtet... Mein Qualitäts Anspruch ans Netz wäre das nicht.

kingpin42 · 11. April 2023

Alles eine Frage der Kosten.

Nachtrag
Von der BNA toleriert wird übrigens alles unter 150ms:

aus https://www.bundesnetzagentur.de/Sh...Gutachten_WIK_zafaco_Mindestanforderungen.pdf

robert_s · 11. April 2023

Holzkopf schrieb:
in 18ms bin ich von Frankfurt - Tschechien - Budapest - Belgrad
in 19ms Frankfurt -Amsterdam - London - Dublin
in 19ms Frankfurt - Zürich - Milan - Rom

Wer 18ms vom Saarland nach Brandenburg als In Ordnung erachtet... Mein Qualitäts Anspruch ans Netz wäre das nicht.

Da bist Du mit weniger als dem Doppelten des physikalisch möglichen aber auch ziemlich optimiert.

Was wäre denn Dein Anspruch für Saarland nach Brandenburg?

Holzkopf · 11. April 2023

kingpin42 schrieb:
Alles eine Frage der Kosten.

Nachtrag
Von der BNA toleriert wird übrigens alles unter 150ms:
Anhang anzeigen 1345529
aus https://www.bundesnetzagentur.de/Sh...Gutachten_WIK_zafaco_Mindestanforderungen.pdf

Was die BNA vorgibt und warum kannst du ja im Text lesen, und was ich als Kunde akzeptiere steht auf einem anderen Blatt.

robert_s schrieb:
Was wäre denn Dein Anspruch für Saarland nach Brandenburg?

Holzkopf schrieb:
Saarland - Brandenburg sollten eher 10ms sein und nicht 18ms.

robert_s · 11. April 2023

Holzkopf schrieb:
Saarland - Brandenburg sollten eher 10ms sein und nicht 18ms.

Damit würdest Du aber von Brandenburg mehr erwarten als von den Metropolen. Wenn Du auf die 600km Luftlinie von Saarbrücken nach Potsdam den gleichen Faktor anwendest wie auf die 1000km von FFM nach Rom, kommst Du schon bei 11ms raus. Und dann sind weder Saarbrücken noch Potsdam Hauptknotenpunkte, also kannst Du das nicht mit einer Verbindung wie z.B. FFM <-> London vergleichen.

Also da würde ich vielleicht 15ms im Backbone ansetzen. Und wenn man dann noch die RTTs auf der "letzten Meile" dazu nimmt, ist man mit 18ms schon recht gut bedient.

Holzkopf · 11. April 2023

Ka was du da für Faktoren heranziehst, die werte die ich genutzt habe sind reale werte von Router zu Router.
Denkst du die Fasern gehen bei Metropole zu Metropole ein direkten weg ? Da irrst du dich gewaltig die gehen durch zig Orte,Städte,Wälder,Felder etc hindurch.
Da ginge sogar noch weniger wenn man es drauf anlegen würde.

Frankfurt - Berlin sind 7ms
Potsdam is ~35km nach Berlin
sagen wa ~7.5ms
Frankfurt Saarbrücken sind ~190km
sind wir bei ~9.5ms

er hat das doppelte und die "letze Meile" fällt nicht an da es direkt die Latenz im Netz war.

Du fändest 18ms minimal Latenz nicht zuviel an deinem Anschluss ?

kingpin42 · 13. April 2023

Holzkopf schrieb:
in 18ms bin ich von Frankfurt - Tschechien - Budapest - Belgrad
in 19ms Frankfurt -Amsterdam - London - Dublin
in 19ms Frankfurt - Zürich - Milan - Rom

Wer 18ms vom Saarland nach Brandenburg als In Ordnung erachtet... Mein Qualitäts Anspruch ans Netz wäre das nicht.

RTT ? Von welchen Zielen aus gemessen ?
Ich hab jetzt diverse Quellen durchforstet, aber bei keiner mir bekannten Strecke zwischen z.B. Frankfurt und Dublin erreicht man 19ms RTT. Alleine Dublin <-> London liegen (beides Equinix RZs) bereits bei ~10ms RTT.
Equinix DB1 nach FR5 (Kleyer 90 in FFM) sind auch ~25ms.

Holzkopf · 13. April 2023

retn und he.net z.b.
haben jeweils 19ms

Code:

x.dub1.he.net> ping ipv6 2001:470:0:63d::1
Reply    2001:470:0:63d::1    19ms

Code:

4. x.RT.IRX.DUB.IE.retn.net    0.0%    10   32.2  21.1  19.2  32.2   3.9

kingpin42 · 13. April 2023

~~Anhang anzeigen 1346727~~
Da unterscheiden sich sogar schon die T1 untereinander, und Lumen hat das größte Fibernetz der Welt.

Selbst hier erreicht man die 19,1ms nur als absoluten Bestwert, bei einer Standardabweichung von 9,2ms !
Zwischen Bestem und Schlechtestem Wert liegen fast 30ms.

Hier sind es auch nicht wirklich 19ms.

Die Angaben von mir weiter vorne im Thread bezogen sich nie auf die Min-Werte, die 18ms sind AVG RTT.

Ich frage mich aber trotzdem noch, wo da der Vorteil zu <10ms RTT zum 1st Hop real sein sollen ? (was nur mit direkter Luftlinien Darkfiber machbar wäre).

Ergänzung (13. April 2023)

Die ursprüngliche Behauptung war ja zudem eine ganz Andere, nämlich, erhöht sich in einem PON-Netzwerk zwangsläufig die Laufzeit. Ich kann mal einen OLT von uns raussuchen mit 2 Linecards, PON und Active Ethernet. Sofern die Kundengeräte dahinter von uns gemanaged werden, ließe sich damit ja eine entsprechende Aussage zum Unterschied treffen.

Holzkopf · 13. April 2023

Lumen routet von Frankfurt über Paris während he und retn über Amsterdam gehen.
Das die Latenzen so schwanken liegt doch daran, das wir hier einen Router als Ziel haben

Und die Control Plane antwortet auf Pings meistens nicht sofort.
Der Min Wert ist in diesem falle wenn man es mehrmals macht ein guter Ansatz was im routing zu erwarten wäre.

Du kannst von he auch Pingen wo es diesen Nachteil nicht gibt.

Code:

core2.dub1.he.net> ping ipv6 2001:470:0:63d::1 numeric count 5 source 2001:470:0:555::1
Count    5
Size    56 bytes
Target    2001:470:0:63d::1
Reply    2001:470:0:63d::1    64    19ms    61
Reply    2001:470:0:63d::1    64    19ms    61
Reply    2001:470:0:63d::1    64    19ms    61
Reply    2001:470:0:63d::1    64    19ms    61
Reply    2001:470:0:63d::1    64    19ms    61
Packet Loss    Received Count    Received Fastest    Received Average    Received Slowest
0%    5/5    19.373ms    19.584ms    19.761ms

0.4ms deviation

Die Min Werte sind vom AVG auch nicht weit entfernt wenn du keine Systeme pingst die nur dann Antworten wenn sie nichts besseres zutun haben.
Kannste schön am He.net result sehen.

kingpin42 schrieb:
Ich frage mich aber trotzdem noch, wo da der Vorteil zu <10ms RTT zum 1st Hop real sein sollen ? (was nur mit direkter Luftlinien Darkfiber machbar wäre).

Latenz bedeutet Verzögerung und das ist nun mal immer schlecht

Und gerade das TCP Protokoll ist sehr empfindlich was da angeht.
Gerade wenn wir mal zu 10G kommen sind 10ms eine menge.
Um mit TCP mit 10G und einer Latenz von 10ms zum Ziel die Leitung zu sättigen bedarf es einem 12.5MB großen Congestion und Receive Window.
Hier ist bei out of the Box Linux Servern schon Feierabend, die haben nur 3.5MB
Hätte ich aber nur 1ms würden 1.25MB reichen.
Bei deinen 18ms brauch ich schon 22MB + die Latenz zum Ziel.
Hier macht Selbst Windows mit Standard Settings schon zu, da das Limit bei 16MB liegt.

Bei 18ms und 3.5Mb Window is bei 1.7Gbit pro Verbindung Schluss.
Muss also auf Multi-Thread setzen.

Ein Gamer wird über 18ms + Latenz zu seinem Server auch nicht Glücklich sein.

kingpin42 schrieb:
Die ursprüngliche Behauptung war ja zudem eine ganz Andere, nämlich, erhöht sich in einem PON-Netzwerk zwangsläufig die Laufzeit. Ich kann mal einen OLT von uns raussuchen mit 2 Linecards, PON und Active Ethernet. Sofern die Kundengeräte dahinter von uns gemanaged werden, ließe sich damit ja eine entsprechende Aussage zum Unterschied treffen.

Für den fall das du noch gewillt bist dinge zu testen die ich anfrage

Was mich interessieren würde.
Ein Ziel das sehr nahe hinter dem OLT sitzt und in der lage ist unter 1ms mit niedriger Deviation verlässlich zu antworten anpingen. (Server Laptop etc.)
Jeweils per Active Ethernet
PON mit 1-4 ONT
PON mit 32-64 mit dementsprechend pi mal daumen vielen aktiven ONTs (ka was für ein verhälltnis ihr Produktiv einsetzt.)

Meine Erwartung:
Active Ethernet klar vorne niedrige Latenz und sehr kleiner Jitter ( siehe he.net Ping )
PON mit 1-4 ONT ähnlich wie AE nur etwas schlechter
PON mit 32-64 ONT höhere Latenz und Jitter.

kingpin42 · 14. April 2023

Holzkopf schrieb:
Lumen routet von Frankfurt über Paris während he und retn über Amsterdam gehen.
Das die Latenzen so schwanken liegt doch daran, das wir hier einen Router als Ziel haben
Und die Control Plane antwortet auf Pings meistens nicht sofort.

Generell machen das vielen, das ist richtig, das ist aber nicht das was ich bei einem, via öffentlichem LG verfügbaren Router erwarten würde. Kann auch ein lokaler Filter sein, der nur ein paar IPs whitelisted, die nicht gedrosselt werden.

Holzkopf schrieb:
Der Min Wert ist in diesem falle wenn man es mehrmals macht ein guter Ansatz was im routing zu erwarten wäre.

Du kannst von he auch Pingen wo es diesen Nachteil nicht gibt.

Code:

core2.dub1.he.net> ping ipv6 2001:470:0:63d::1 numeric count 5 source 2001:470:0:555::1 Count 5 Size 56 bytes Target 2001:470:0:63d::1 Reply 2001:470:0:63d::1 64 19ms 61 Reply 2001:470:0:63d::1 64 19ms 61 Reply 2001:470:0:63d::1 64 19ms 61 Reply 2001:470:0:63d::1 64 19ms 61 Reply 2001:470:0:63d::1 64 19ms 61 Packet Loss Received Count Received Fastest Received Average Received Slowest 0% 5/5 19.373ms 19.584ms 19.761ms

0.4ms deviation

Ok, das ist jetzt ein Beispiel von ~19ms, allerdings wäre auch das für den User relativ irrelevant, der hängt ein paar Hops weiter hinten und hat durch die aktiven Komponenten definitiv eine höhere Latenz. Man müsste jetzt den Faserverlauf und die Anzahl an Zwischenknoten bei HE kennen, evtl. ist das auch eine "direkte" optische Verbindung mit lediglich ein paar ROADMs zur Verstärkung dazwischen, anstatt MPLS Hops.

Holzkopf schrieb:
Latenz bedeutet Verzögerung und das ist nun mal immer schlecht

Ja, in gewissem Maße ist diese aber unbedenklich.

Holzkopf schrieb:
Und gerade das TCP Protokoll ist sehr empfindlich was da angeht.

Gerade das Protokoll ist überhaupt nicht empfindlich, siehe RFC1323, seit 1992 proposed standard.

Holzkopf schrieb:
Gerade wenn wir mal zu 10G kommen sind 10ms eine menge.
Um mit TCP mit 10G und einer Latenz von 10ms zum Ziel die Leitung zu sättigen bedarf es einem 12.5MB großen Congestion und Receive Window.
Hier ist bei out of the Box Linux Servern schon Feierabend, die haben nur 3.5MB
Hätte ich aber nur 1ms würden 1.25MB reichen.
Bei deinen 18ms brauch ich schon 22MB + die Latenz zum Ziel.
Hier macht Selbst Windows mit Standard Settings schon zu, da das Limit bei 16MB liegt.

Bei 18ms und 3.5Mb Window is bei 1.7Gbit pro Verbindung Schluss.
Muss also auf Multi-Thread setzen.

https://www.rfc-editor.org/rfc/rfc1323.txt
Das Receive Window ist schon lange kein starrer Wert mehr:

Windows scaling
For more efficient use of high-bandwidth networks, a larger TCP window size may be used. The TCP window size field controls the flow of data and is limited to 2 bytes, or a window size of 65,535 bytes.

Since the size field can't be expanded, a scaling factor is used. TCP window scale is an option used to increase the maximum window size from 65,535 bytes to 1 Gigabyte.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/description-tcp-features

Linux kann das auch:

The maximum TCP window size that can be achieved using TCP window scaling is for a scaling factor of 2^14=16,384, which would give a window size of 16,384 x 65,535 = 1,073,725,440 bytes, or approximately 1 GB.

https://www.site24x7.com/learn/linu... TCP window size,bytes, or approximately 1 GB.

Holzkopf schrieb:
Ein Gamer wird über 18ms + Latenz zu seinem Server auch nicht Glücklich sein.

Valider Punkt, allerdings frage ich mich, ob ein Gamer einen Unterschied zwischen 10 oder 18 ms RTT bemerken würde. Auf 1ms oder einer Latenz wie im LAN kommt man jedenfalls nie im WAN.

Holzkopf schrieb:
Für den fall das du noch gewillt bist dinge zu testen die ich anfrage

Was mich interessieren würde.
Ein Ziel das sehr nahe hinter dem OLT sitzt und in der lage ist unter 1ms mit niedriger Deviation verlässlich zu antworten anpingen. (Server Laptop etc.)
Jeweils per Active Ethernet
PON mit 1-4 ONT
PON mit 32-64 mit dementsprechend pi mal daumen vielen aktiven ONTs (ka was für ein verhälltnis ihr Produktiv einsetzt.)

Meine Erwartung:
Active Ethernet klar vorne niedrige Latenz und sehr kleiner Jitter ( siehe he.net Ping )
PON mit 1-4 ONT ähnlich wie AE nur etwas schlechter
PON mit 32-64 ONT höhere Latenz und Jitter.

Ja muss ich nur schauen wie ich das bei uns testen kann. Wir haben Odroids im Netz für Qualitätsmessungen (unter anderem auch Latenzen), die hängen afaik direkt an PON-Segmenten in verschiedenen Gegenden.
Splits haben wir auch unterschiedliche, meist jedoch 1:32 (seltener auch 1:16). Größere Splits eigentlich nur im Testlab.

Holzkopf · 14. April 2023

Die Empfindlichkeit bezog sich auf Latenz im Bezug auf Speed.

Die 3.5MB bei Linux bzw 16MB bei Windows bezogen sich auf das Obere effektive Limit der Skalierung.
Mehr wie das geht out of the Box nicht.
Willst du mehr musst du es Manuel anpassen.

kingpin42 · 14. April 2023

Welches obere Limit der Skalierung soll das sein ?
OOtB ist o.g. Window Scaling aktiv, das ein RWIN von bis zu 1GB ermöglicht.

Inwiefern soll Latenz bei TCP eine große Rolle spielen ?
Will ich die niedrigst möglichen Latenzen für meine Anwendung, mache ich einen Bogen um TCP.

Holzkopf · 14. April 2023

kingpin42 schrieb:
Welches obere Limit der Skalierung soll das sein ?

Die Maximale Buffer größe. Windows Arbeit mit Scaling Factor.
Bei TuningLevel normal der ootb standard eingestellt ist sind es 8x was 256 entspricht 65535x256=16.776.960 = 16MB
TuningLevel Experimental erhöht den Faktor auf 14x was 16384 entspricht 65535x16384=1,073,725,440 = 1GB
Bei Linux kannste den Buffer in der Größe direkt angeben. Ootb ist das obere Limit 7MB wovon Linux die hälfte für den eigentlich Buffer zur verfügung stellt, was 3.5MB entspricht.

kingpin42 schrieb:
OOtB ist o.g. Window Scaling aktiv, das ein RWIN von bis zu 1GB ermöglicht.

Nein es ist nicht bis 1GB aktiv, die Limits stehen oben.

kingpin42 schrieb:
Inwiefern soll Latenz bei TCP eine große Rolle spielen ?

Bin jetzt echt verwundert das du den Zusammenhang zwischen Latenz und throughput bei TCP nicht kennst.

kingpin42 schrieb:
Will ich die niedrigst möglichen Latenzen für meine Anwendung, mache ich einen Bogen um TCP.

Kannst deine Daten ja per UDP übertragen, toi toi das sie heile ankommen

P.s. Genug Offtopic und Erklärereien

kingpin42 · 15. April 2023

Holzkopf schrieb:
Die Maximale Buffer größe. Windows Arbeit mit Scaling Factor.
Bei TuningLevel normal der ootb standard eingestellt ist sind es 8x was 256 entspricht 65535x256=16.776.960 = 16MB
TuningLevel Experimental erhöht den Faktor auf 14x was 16384 entspricht 65535x16384=1,073,725,440 = 1GB
Bei Linux kannste den Buffer in der Größe direkt angeben. Ootb ist das obere Limit 7MB wovon Linux die hälfte für den eigentlich Buffer zur verfügung stellt, was 3.5MB entspricht.

Hast du eine Quelle zu den 3.5MB ? Wenn ich via

Bash:

ss -tm

mir die Buffer für einen iperf3 TCP Run anschaue, entspricht das bei einem Debian 10, wo nichts bei den sysctls verändert wurde, eher 6MB:

Bash:

root@xxx-root:~# sysctl net.ipv4.tcp_rmem
net.ipv4.tcp_rmem = 4096        87380   6291456
root@xxx-root:~# sysctl net.ipv4.tcp_wmem
net.ipv4.tcp_wmem = 4096        16384   4194304

Und selbst das hängt wohl eher davon ab, was die Applikation für sich via SO_RECVBUF und SO_SNDBUF Socketoption fordert:

This is a good time to check whether the application calls setsockopt(SO_RCVBUF). If the application does call this function, this will override the default settings and turn off the socket's ability to auto-tune its size. The size of the receive buffer will be the size specified by the application and no greater.

https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf

Holzkopf schrieb:
Nein es ist nicht bis 1GB aktiv, die Limits stehen oben.

Doch, ist es, da TCP Window Scaling, zumindest unter den gängigen Distributionen, als sysctl per default aktiv gesetzt ist:

Bash:

root@xxx-root:~# sysctl net.ipv4.tcp_window_scaling
net.ipv4.tcp_window_scaling = 1

Holzkopf schrieb:
Bin jetzt echt verwundert das du den Zusammenhang zwischen Latenz und throughput bei TCP nicht kennst.

Wo liest du das raus ?

Holzkopf schrieb:
Kannst deine Daten ja per UDP übertragen, toi toi das sie heile ankommen

Hängt alles von der darüberliegenden Schicht ab, wird schon Gründe haben, warum man für HTTP/3 auf QUIC und damit UDP setzt.

Holzkopf schrieb:
P.s. Genug Offtopic und Erklärereien

Darf ein Moderator gerne in einen separaten Thread kapseln.

Glasfaser Latenzen in Glasfaser-Netzen

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Windows scaling​

Lieutenant

Lt. Junior Grade

Lieutenant

Lt. Junior Grade

Ähnliche Themen

Windows scaling