Bericht Glasfaser: Die Suche nach dem schnelleren Licht

[conf_t]

@

unterseekabel sollen etwas länger sein, habe ich gehört wenn das dann dort mal ankommt, hat das bei den längen dann schon durchaus spürbare effekte.

Auch bei Unterseekabeln sinkt die reine Ausbreitungslatenz dadurch maximal um etwa ein Drittel. Ein Drittel bleibt ein Drittel – ob im LAN, WAN oder globalen WAN. Absolut kann das auf langen Strecken natürlich deutlich mess- und spürbar sein; relativ bleibt es aber bei dieser Größenordnung. Mehr wäre nur möglich, wenn sich das Signal schneller als mit Lichtgeschwindigkeit im Vakuum ausbreiten könnte.

Zwischen Frankfurt und New York wären das bei idealisierter direkter Strecke beispielsweise etwa 30 statt 20 ms in eine Richtung. Technisch ist das ohne Frage bedeutend. Eine Anwendung, die mit 30 ms grundlegende Probleme hat, wird durch 20 ms aber nicht plötzlich unkritisch. Es ist eine spürbare quantitative Verbesserung, aber kein qualitativer Sprung. Ich habe ja vorhin nicht behauptet, es sei nicht spürbar, aber eben nur bei einer Verbesserung von rd. 1/3

 

[Pringel]

Ja. Neuer Titel... Gar nicht bemerkt. Erst dann verstanden was Oldtimer meint

@0x8100
Das wird erstmal so ein KI co-optics Gedöns bleiben -> Da wo 1/3 weniger Latenz auch real was ausmacht.

Wie gesagt bzw. gemeint, Übertragung ist die eine Metrik, aber wir werden - auch da - noch eine halbe Ewigkeit nichts haben um das auch zu verarbeiten. Schon die 400 Tb/s die mit der halbwegs gewöhnlichen Faser gehen könnten, sind 50 TB/s. Wir können bisher 102 Tb switchen. Mit 1kW

Kontinente verbinden, ok

 

[0x8100]

Bei Fra <-> New York wären das dann eben statt rund 30 ms eben rund 20 ms.

pro richtung, wenn die rtt von 60 auf 40 sinkt, ist das natürlich immer noch ein drittel, aber es wird dann schon relevanter.

 

[Pringel]

Lasst uns erstmal diese 400 Tbit/s pro Faser schaffen (produktiv) und dann gucken wir mal weiter

 

[conf_t]

pro richtung, wenn die rtt von 60 auf 40 sinkt,

30 statt 20 ms in eine Richtung

Genau das habe ich bereits geschrieben: rund 30 statt 20 ms pro Richtung, also etwa 60 statt 40 ms RTT. Dass die absolute Ersparnis auf langen Strecken relevanter wird, habe ich ebenfalls ausdrücklich eingeräumt. Belibt aber auch weiterhin "nur" 1/3 Erpsarnis. Eine lahme Anwendung wird damit nicht pfeilschnell.

Du wiederholst damit gerade lediglich meinen Punkt, als wäre es ein Einwand dagegen. Im Großen und Ganzen bin ich bei deinen Beiträgen in diesem Thread, aber hier versuchst du inzwischen mehrfach, mir etwas entgegenzuhalten, das in meinem Beitrag bereits berücksichtigt ist. 🤦‍♂️

Melde dich gern wieder, wenn du inhaltlich etwas Neues dazu beizutragen hast.

 

[harnwegsinfukfu]

Endlich... Meine 10 GBit/s momentan stoßen beim YouTube schauen WIRKLICH an ihre Grenzen.

 

[JustAnotherUser]

Das machen die großen Streaming-Dienste doch schon längst...

Zum einen ist das immer ncoh gigantisch viel ineffizienter als Rundfunk und zum anderen dominiert das ja schon längst nicht mehr die Anforderungen. Netflix zB empfielt 15 MBit/s für eienn 4K Stream, das ist ja nehezu nichts.

 

[0x8100]

Belibt aber auch weiterhin "nur" 1/3 Erpsarnis. Eine lahme Anwendung wird damit nicht pfeilschnell. [...] Melde dich gern wieder, wenn du inhaltlich etwas Neues dazu beizutragen hast.

warum so angefressen? dass die latenz wichtig ist, sollte doch bekannt sein:

2,5 Gb/s ohne latenz:

$ iperf3 -c 192.168.1.3
Connecting to host 192.168.1.3, port 5201
[  5] local 192.168.1.22 port 37768 connected to 192.168.1.3 port 5201
...
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.74 GBytes  2.36 Gbits/sec    0            sender
[  5]   0.00-10.00  sec  2.74 GBytes  2.35 Gbits/sec                  receiver

60ms latenz:

$ tc qdisc add dev enp5s0 root netem delay 60ms
$ iperf3 -c 192.168.1.3
Connecting to host 192.168.1.3, port 5201
[  5] local 192.168.1.22 port 39856 connected to 192.168.1.3 port 5201
...     
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   440 MBytes   369 Mbits/sec    0            sender
[  5]   0.00-10.06  sec   440 MBytes   367 Mbits/sec                  receiver

40ms latenz:

$ tc qdisc change dev enp5s0 root netem delay 40ms
$ iperf3 -c 192.168.1.3
Connecting to host 192.168.1.3, port 5201
[  5] local 192.168.1.22 port 52028 connected to 192.168.1.3 port 5201
...
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   663 MBytes   556 Mbits/sec    0            sender
[  5]   0.00-10.04  sec   663 MBytes   554 Mbits/sec                  receiver

löschen nicht vergessen:

$ tc qdisc del dev enp5s0 root

und wenn man "einfach" durch ein anderes kabel ein paar hundert Mbit mehr haben kann? gerne

 

[JustAnotherUser]

aber die Latenz ist für manche Fälle noch immer zu hoch.

Ja klar, vorallem für Marktmanipulation an Börsen

Was man für Klimmzüge machen muss um NTP genau zu bekommen, wenn es auf Timstaps auf die 10tel Milisekunde ankommt.....

Und wo kommt es darauf an?

 

[conf_t]

@0x8100
Ich bin nicht angefressen, du widerlegst nur weiterhin nichts von dem, was ich geschrieben habe. Scheinst es aber verzeifelt zu versuchen.

Dein Test demonstriert in erster Linie das Bandwidth-Delay-Product bei einem offenbar begrenzten TCP-Fenster. Die Werte passen sogar nahezu exakt zusammen:

369 Mbit/s × 60 ms ≈ 2,77 MB
554 Mbit/s × 40 ms ≈ 2,77 MB

Bei gleich großem TCP-Fenster steigt der maximal mögliche Durchsatz durch die Reduktion von 60 auf 40 ms erwartungsgemäß um den Faktor 1,5. Das ist genau die Folge davon, dass die Latenz um ein Drittel sinkt. Niemand hat bestritten, dass dies technisch relevant ist oder bei TCP mehr Durchsatz ermöglichen kann.

Es macht aus einer Anwendung, deren Architektur mit 60 ms schlecht funktioniert, dennoch keine grundsätzlich schnelle Anwendung. Zudem wäre zu klären, ob du tatsächlich 60 beziehungsweise 40 ms RTT getestet hast: tc netem delay 60ms auf einem einzelnen Egress fügt zunächst 60 ms in dieser Richtung hinzu und setzt nicht automatisch die gesamte RTT auf 60 ms.

Und ja: Kann man diese Verbesserung ohne sonstige Nachteile durch einen Fasertausch erhalten, nimmt man sie selbstverständlich mit. Genau deshalb schrieb ich von einer technisch bedeutenden, aber evolutionären Verbesserung. Du belegst meinen Punkt, statt ihm zu widersprechen. Würde dein R-Window in deinem Test nicht limitieren, würdest du gar keinen Durchsatzunterschied merken. Latenz wird bei Bandbreite erst interessant, wenn das R-Window limitiertsprich man im Softwarelimit ist - oder es zu Paketverluste kommt.

@JustAnotherUser Nein, neben Börse auch Packetbroker, wenn man später ein Multipoint Capture von Packetbrokern mergen will. Und genau da wird NTP aufwendig: lokale Zeitserver, kurze und möglichst symmetrische Wege, Hardware-Timestamping, PPS/GNSS und saubere Clock-Disziplinierung. Mit „einfach irgendeinen NTP-Server eintragen“ ist es dann nicht mehr getan.

 

[Blutschlumpf]

und wenn man "einfach" durch ein anderes kabel ein paar hundert Mbit mehr haben kann? gerne

Dafür gibt's ja TCP Window Scaling.

 

[conf_t]

Eben mit 20 oder gar 24 MB R-Window merkt man nichts von der 60 ms Latenz bei ner 2,5 Gbps Karte.

Zum ausprobieren

iperf3 -c 192.168.1.3 -w 24M -t 30

 

[Pringel]

Ah so... Das ist die Faser für die z18 Infrastruktur. "Ich verstehe"

Sehr spannend

 

[0x8100]

Dafür gibt's ja TCP Window Scaling.

was default an ist.

Eben mit 20 oder gar 24 MB R-Window

was man auf beiden seiten konfigurieren muss und damit meistens nicht in der eigenen hand hat.

 

[Fisico]

Schön für all jene die sich an ihrem Kupfer erfreuen und restlos zufrieden sind.
Ebenso gibt es die Gegenseite wie mich, der sich an seinem vollwertigen Glasfaser Anschluss erfreut.
Die 500/100 nutze ich nicht komplett dauerhaft, jedoch wenn ich größere Downloads aufgrund riesiger Updates habe, bleibt die Wartezeit gering.
Noch wichtiger ist mir aber der sehr gute Ping + extrem geringen Packet Loss im kompetitiven Online Gaming, der mir messbare Vorteile verschafft.
Zu Kupfer will ich nicht zurück.

 

[conf_t]

was man auf beiden seiten konfigurieren muss und damit meistens nicht in der eigenen hand hat.

Das muss man in diesem Fall vor allem für den künstlichen iperf3-Test explizit setzen, da er ja offensichtlich bei dir eben nicht das potenzial des möglichen TCP-Receive-Window ausnutzt. Bei normaler TCP-Kommunikation skalieren moderne TCP/IP-Stacks das Receive Window standardmäßig automatisch bis zu ihren jeweiligen Grenzen. Je nach Betriebssystem und Konfiguration liegen diese typischerweise in einer Größenordnung von etwa 16 bis 32 MB.

Damit wären 2,5 Gbit/s bei 60 ms RTT grundsätzlich kein außergewöhnliches Szenario. Ob es praktisch erreicht wird, hängt natürlich zusätzlich vom Congestion Window, der Anwendung und gegebenenfalls von vorgeschalteten Loadbalancern oder Proxies ab.

Dass man die Gegenstelle nicht selbst konfigurieren kann, ist daher zwar formal richtig, aber moderne Gegenstellen arbeiten normalerweise ebenfalls mit Window Scaling und Autotuning. Der iperf3-Test mit konstant etwa 2,77 MB „in flight“ zeigt vor allem ein konkretes Fensterlimit dieses Tests – nicht eine allgemeine Eigenschaft von TCP über 60 ms.

Für Privatanwender ist die ganze Fragestellung ohnehin weitgehend akademisch. Die meisten Dienste werden über CDNs, regionale Edge-Standorte und Anycast möglichst nah bereitgestellt. Echte Langstreckenverbindungen, bei denen ein einzelner TCP-Stream dauerhaft mehrere Gigabit über 60 ms RTT auslasten muss, sind im normalen Alltag eher die Ausnahme.

 

[JustAnotherUser]

@JustAnotherUser Nein, neben Börse auch Packetbroker, wenn man später ein Multipoint Capture von Packetbrokern mergen will. Und genau da wird NTP aufwendig: lokale Zeitserver, kurze und möglichst symmetrische Wege, Hardware-Timestamping, PPS/GNSS und saubere Clock-Disziplinierung. Mit „einfach irgendeinen NTP-Server eintragen“ ist es dann nicht mehr getan.

Und was bitte ist ein Packetbroker ? Und wieso braucht es da so präzise gloal abgestimmte Uhren?

 

[Holzkopf]

Das nutzbare TCP Window Limit von Linux ist nur 3MB default und das sind die meisten Server.

 

[Pringel]

Schön für all jene die sich an ihrem Kupfer erfreuen und restlos zufrieden sind.
Ebenso gibt es die Gegenseite wie mich, der sich an seinem vollwertigen Glasfaser Anschluss erfreut.

Thread komplett verfehlt

 

[Nuklon]

Ich hab da nichts davon gemerkt.
Bei meinem Galaxy J7 sind die Akkus alle drei Jahre in die ewigen Jagdgründe gegangen.
Und billiger waren die Nachfolger auch nicht.

Wunderkapazitäten gab es nicht und da bin ich auch sehr skeptisch, wenn da 6.000 mAh statt 3.000 mAh drauf steht.

Bei Glasfasern mag das anders ein, aber auch da ist die Lichtgeschwindigkeit immer gleich.

Erstens gibt es noch mehr Akkus als Smartphones.
Die für Autos, stationäre für Balkons, Häuser Industrieanlagen und z.b für Kopfhörer haben sich massiv weiterentwickelt. Es gibt Züge, Busse und Schiffe mit Akkus. Und auch dein Smartphoneakku belegt weniger Fläche bei doppelter Größe.

Bei Smartphones ist das Problem das die Hersteller nicht in die Laufzeit sondern in Leistung, Ladezeit und Größe im Gerät investieren. Es entsteht damit der Eindruck das nichts mehr geht. Aber versuch mal dein Akku von 2012 in 30 Minuten von 20 auf 80% zu laden🤪