Glasfaserausbau

hed
Level 7
Level 7
521 von 804

@Sascha-72 

 

Selbst wenn die Firma 1 Gig Glas hat, so sind die limitierenden  Faktoren oft der VPN-Server, Loadbalancer, Firewall und Fileserver. Selbst bei Firmen deren RZ mit nx1Gig oder 10 Gig am Internet hängen ist in den meisten Fällen von remote nicht mehr als 200 - 300 Mbit/s möglich. 

Sascha-72
Level 2
522 von 804

Meinst du, die Firma, welche täglich mit riesigen Datenmengen hantiert, ist nicht entsprechend ausgelegt? 

Ich kenne das RZ und verlass dich drauf... die dort verbauten Komponenten können damit umgehen... inklusive VPN-Traffic.

 

Einfach bitte mehr Flughöhe einnehmen, die von dir angesprochenen "Limiten" sind, mit der richtigen Hardware, leicht zu umgehen.

hed
Level 7
Level 7
523 von 804

@Sascha-72 

 

Mit dem nötigen Aufwand ist alles machbar, nur betreiben die Firmen ihre RZ nicht zum Hobby wo das Geld resp. die Rentabilität keine Rolle spielt. Ich habe schon viele Performancemessungen gemacht in Firmen und bei grossen Cloud-Anbietern und ich war immer wieder erstaunt, wie tief die Nettoraten besonders in Spitzenzeiten sind. Und selbst bei  Firmen/Plattformen/RZ/Cloud-Anbietern die eine E2E-Performance von 1 Gigabit oder ein mehrfaches davon bieten, teilen sich diese Bandbreite in der Regel eine grosse Anzahl von Mitarbeitern und/oder Kunden.

 

Was man bei der ganzen Thematik ebenfalls berücksichtigen muss, ist die Limitierung der Uebertragungsgeschwindigkeit bei TCP durch die Flussteuerung und das dafür verwendete Window Scaling nach folgender Formel:

 

Max. Durchsatz (in bit/s) = TCP Window Size (in bit) / Latenz (in s)

 

In vielen RZ werkeln noch Server, deren Window Size bei max. 2 Mbyte (= 16 Mbit) liegt. Bei einer typischen Latenz von 30ms (z.B. bei der MS Azure - Cloud) ist somit die maximale Brutto-Uebertragungsgeschwindigkeit 530 Mbit/s, selbst wenn man an einem 10 Gig Schlauch hängt.

Editiert
Tux0ne
Level 9
524 von 804

Wenn man wissen will, wie lange das noch dauern könnte (aber nicht muss): https://youtu.be/EyXZYZk7NOM?t=2620

Und hier direkt das ganze Video vom Propagandasender Digitale Gesellschaft 😉 https://www.youtube.com/watch?v=EyXZYZk7NOM

 

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
GrandDixence
Level 1
525 von 804

In vielen RZ werkeln noch Server, deren Window Size bei max. 2 Mbyte (= 16 Mbit) liegt.  ist somit die maximale Brutto-Uebertragungsgeschwindigkeit 530 Mbit/s, selbst wenn man an einem 10 Gig Schlauch hängt.

Eine maximale TCP Window Size von nur 2 Megabyte wird sicher nicht von einem aktuellen Windows-Betriebssystem verursacht. Seit Windows Vista ist die maximale TCP Window Size von Windows-Betriebssysteme in der Standardkonfiguration 16 Megabyte oder grösser.

 

https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc162519(v=msdn.10)

 

https://docs.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-pe...

 

Die Standardkonfiguration von aktuellen Windows-Betriebssytemen ist:

 

Receive Window Auto-Tuning Level : normal

 

Auch aktuelle Linux-Installationen unterstützen eine ordentlich grosse TCP Window Size. Jedoch ist bei Linux mit Standardkonfiguration die maximale TCP Window Size kleiner 16 Megabyte. Deshalb betreibe ich bei Linux-Installationen ein wenig Host-Tuning:

 

/etc/sysctl.conf

# TCP Window vergrössern auf
# 16 MegaByte TCP-Window Size (analog zu Windows Vista/7)
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 16384 33554432

 

Siehe dazu auch: # man tcp   => https://linux.die.net/man/7/tcp

 

Viele Hardware- und Software-Komponenten zwischen TCP-Server und TCP-Client können negativen Einfluss auf die maximale TCP Window Size haben. Bekannt ist der negative Einfluss von Windows-Rechnern mit Antivirus-Software.

 

Solche negative Einflüsse können mit dem Auswerten von Netzwerkdatenverkehrsaufzeichnungen in Wireshark entdeckt werden. Alternativ können auch LFN-Tests mit schnellen Servern in Japan durchgeführt werden (LFN => Long Fat Network):

 

https://ftp.jaist.ac.jp/

 

https://ftp.iij.ad.jp/

 


Bei einer typischen Latenz von 30ms (z.B. bei der MS Azure - Cloud)

Bei einer Paketumlaufzeit (RTT) von grösser 25 Millisekunden geht das schon in Richtung "Long Fat Network" (LFN). Bei LFN könnte ein "Host Tuning" erforderlich sein:

https://fasterdata.es.net/host-tuning/

 

https://de.wikipedia.org/wiki/Verz%C3%B6gerungs-Bandbreiten-Produkt

 

Wie die maximale TCP Window Size die maximal mögliche Datenübertragungsrate einschränkt, kann man mit dem "TCP Throughput Calculator" von Switch berechnen:

https://www.switch.ch/network/tools/tcp_throughput/

 

https://community.swisscom.ch/t5/Internet-Allgemein/IB3-erreicht-nur-2-4-gbit-down-up-anstatt-10-gbi...

Editiert
hed
Level 7
Level 7
526 von 804

@GrandDixence 

 

Richtig, die maximale WinSize moderner OS ist 16 MB (64 KB x 256 Overscaling),  die Realität zeigt allerdings, dass noch längst nicht alle Systeme mit 16 MB laufen. Teilweise wird das auch manuell auf 2 MB begrenzt, um die max. Datenrate pro TCP-Stream auf einfache Art und Weise bewusst zu limitieren. Da hilft ein Tuning auf der Client-Seite nichts, weil du auf die Einstellungen im RZ der Firma oder des Cloud-Dienstleisters keinen Einfluss hast. 

 

Hinzu kommt, dass die 16 MB ein theoretisches Maximum darstellen. Jeder Packet-Loss und jeder Overflow z.B. in einer Input-Queue reduzieren die WinSize im Sinne der TCP-Flusssteuerung. 

 

Die genannten 30ms sind ein üblicher Wert z.B. von Azure RZ in Zürich. Hier kannst du Live den Delay von zwei grossen Cloud-Anbietern (AWS-Cloud und MS-Azure) für die verschiedensten Standorte anschauen:

 

Aws Latency Test - AWS Speed Test

Azure Latency Test - Azure Speed Test

 

Azure Zürich zeigt aktuell 15ms an, diesen Wert musst du mit 2 multiplizieren um die RTT zu bekommen, womit wir bei den erwähnten 30ms sind.  Die geringste Latency von AWS ist derzeit Frankfurt mit 40ms = 80 ms RTT. 

Tux0ne
Level 9
527 von 804

Sehr OT. Aber ich würde die Latenzen mal prüfen lassen. Selbst auf dem Mobilen Netz von Sunrise sind wir unter 10ms. 
Bei Fiber7 unter 2ms.

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
Sascha-72
Level 2
528 von 804

Azure Zürich zeigt aktuell 15ms an, diesen Wert musst du mit 2 multiplizieren um die RTT zu bekommen, womit wir bei den erwähnten 30ms sind.  Die geringste Latency von AWS ist derzeit Frankfurt mit 40ms = 80 ms RTT. 


Das ist nachvollziehbar, da die Pakete aus dem Ausland zolltechnisch behandelt werden müssen... 🤐

 

Spass beiseite... 

Ich weiss jetzt nicht, ob die sich bewusst mit Paketgrössen auseinandergesetzt haben, aber laut Aussage von deren IT schaffen "potente" externe Dienstleister durchaus um die 700 - 800MB/s

 

Das ist deren Daily-Business, dass sie grosse Datenmengen hin- und herbewegen. 

 

Sobald hier mal die Glasleitung freigeschaltet werden darf, werde ich das ganz bestimmt testen. 

Werner
Super User
529 von 804

@Sascha-72 

 

Bei den mit 700-800 Mbit/sec öffentlich erreichbaren  Cloud-Serviceprovidern würde ich mal noch ca. die Hälfte als reine Marketingphantasie abziehen.

 

Die Praxiserfahrung von verschiedenen Teilnehmern hier im Forum zeigt auf einen aktuell erreichbaren Server-seitigen Maximalwert von ca. 300 Mbit/sec.

 

Und da spreche ich jetzt nicht von der neu zahlungspflichtigen Swisscom myCloud, denn da solltest Du noch bedeutend weniger an Leistung erwarten…

Selbstdeklaration: Emanzipierter Kunde und Hobby-Nerd ohne wirtschaftliche Abhängigkeiten zur Swisscom
Selbstdeklaration: Emanzipierter Kunde und Hobby-Nerd ohne wirtschaftliche Abhängigkeiten zur Swisscom
hed
Level 7
Level 7
530 von 804

@Tux0ne  schrieb:

Sehr OT. Aber ich würde die Latenzen mal prüfen lassen. Selbst auf dem Mobilen Netz von Sunrise sind wir unter 10ms. 
Bei Fiber7 unter 2ms.


@Tux0ne 

 

Die erwähnte Latenz ist nicht zu vergleichen mit einem nahezu wertlosen ICMP-Ping mit 64 Byte grossen Paketen bis zum Router des RZ sondern mit realistischen, 1500 Byte grossen TCP-Paketen bis zu den Servern der Cloud.  D.h. es ist die Service-Latenz und die zählt letztendlich in der Formel zur Bestimmung der maximalen Datenrate.

hed
Level 7
Level 7
531 von 804

@Sascha-72 

 

Du meinst wohl 700 - 800 Mbit/s und nicht 700 - 800 MB (=  5.6 - 6.4 Gbit/s), oder?

 

Und ja, grosse Cloud-Anbieter schaffen auch noch wesentlich mehr d.h. z.T. zig Gbit/s und sie werben auch damit. Aber die Werbung bezieht sich dann auf gesamte Bandbreite welche das RZ stemmen kann. Nur besteht da ein gewaltiger Unterschied zu einer einzelnen TCP-Session. Logisch können z.B. in einer Grossfirma welche mit 10 Gig am Internet hängt, 20 Leute gleichzeitig einen Upload mit je 300 - 400 Mbit/s in die Azure Cloud machen (= 20 parallele TCP-Sessions). Das heisst aber noch lange nicht, dass ein einzelner User der alleine an diesem Schlauch hängt dann die 6 - 8 Gbit/s erreichen kann. Und damit wären wir wieder beim alles entscheidenden Thema TCP-WindowSize,  TCP-Flussteuerung und Latenz, welche die max. erreichbare Uebertragungsrate massgeblich limitieren.

 

Nachfolgend ein Versuch,  die Formel "Max. Durchsatz (in bit/s) = TCP Window Size (in bit) / Latenz (RTT) (in s)" möglichst einfach zu erklären:

 

Gemäss TCP-Protokoll darf ein Sender ohne Empfangsbestätigung (Ack) vom Empfänger nur eine bestimmte Anzahl Bits  übertragen. Diese Anzahl xy ist durch die WindowSize definiert. Nun werden also die xy Bits vom Client auf die Reise geschickt was eine bestimmte Zeit (Latency) bis zur Ankunft benötigt. Wenn das letzte Bit beim Empfänger eintrifft, sendet dieser ein Ack zum Absender, welches wiederum  eine bestimmte Zeit (Latentcy) auf dem Rückweg zum Sender braucht. Erst wenn dieses Ack eingetroffen ist, darf der Sender die nächste Anzahl xy Bits wieder zum Empfänger senden.

 

Daraus ergibt sich: Je grösser die WindowSize und je kleiner die Latenz, umso höher der Durchsatz.

Editiert
Plereippeg66
Level 2
532 von 804

@Werner 

 

Danke für den Hinweis. Ich habe die Fakten meiner Aussage nochmals überprüft.

 

- Den Brief dass der Glasfaserausbau auf unbestimmte Zeit verschoben ist, habe ich selbst erhalten.

- Mehrere Neubauten die ich erwähnt habe wurden  tatsächlich NUR mit Glasfaser in P2MP erschlossen und auch aktiviert.

- Eines der Gebäude wird jetzt bezugsfertig.

- Für alle Adressen der neuen Bauten gibt auch der Checker 10Gb verfügbar an.

 

 

Was wo in welchem Urteil oder Verodnung steht ist mir mittlerweile so was von egal ......

 

Fakt ist doch einfach dass das von "Freddy" losgetretene WEKO Theater gerade für die Bewohner ländlicher Gebiete einfach nur "Schikane" bedeutet .......  (der weitere Satz,  kann sich jeder selbst zurechtlegen....) 

 

 

Silverfish1999
Level 2
533 von 804

@Werner 

 

Wo du recht hast, hast du recht, Punkt!

hed
Level 7
Level 7
534 von 804

@Plereippeg66  schrieb:

@Werner 

...

Was wo in welchem Urteil oder Verodnung steht ist mir mittlerweile so was von egal ......

...


@Plereippeg66 

 

Möglicherweise ist es dir egal, aber letztendlich ist es entscheidend, wie es in dieser Angelegenheit weiter geht.

 

Beeinflussen können wir das selbst nicht, das ist aber auch nicht nötig. Ich vertraue unserem Rechtsstaat, dass er dies korrekt regeln wird.

Zuvedi97
Level 2
535 von 804

@Plereippeg66 Hier in der Gegend gibt es das absolut selbe Verhalten. Neubauten werden P2MP-only erschlossen und bestehende FTTB Installationen gehen leer aus.

 

Bei einem Bekannten mit bestehender FTTB-Installation hat der Status vor drei Wochen ganz plötzlich vom bekannten "Leider wurde der Ausbau dieses Standortes verschoben." auf "Das Gebäude ist mit Glasfaser erschlossen (Hausanschluss vorhanden). Sie benötigen zur Glasfaser-Nutzung eine Glasfaser-Dose innerhalb der Wohnung." gewechselt und er kann nun FTTH bestellen.

 

Ich frage mich schon, warum manche Standorte (illegal?) bevorzugt behandelt werden!?

 

Nicht dass ich deshalb sofort zur WEKO rennen würde, wie die Künzler-Anhänger, die vermutlich alle bereits FTTH in der Stube liegen haben.

 

hed
Level 7
Level 7
536 von 804

@Plereippeg66  schrieb:

@Werner 

 

Fakt ist doch einfach dass das von "Freddy" losgetretene WEKO Theater gerade für die Bewohner ländlicher Gebiete einfach nur "Schikane" bedeutet .......  (der weitere Satz,  kann sich jeder selbst zurechtlegen....) 

 

 


@Plereippeg66 

 

Init 7 macht letztendlich nur das, was jede Aktiengesellschaft machen muss:

 

Mit legalen Mitteln das Maximum für die Firma, die Aktionäre und die Kunden herausholen.

 

Nein, ich bin kein Fan-Boy von Init7, denn ich bin selbst auch vom Stop betroffen. Aber ich respektiere den rechtsstaaatlichen Weg den Init7 beschritten hat, auch wenn es in diesem Fall zu meinem  Nachteil ist.

Werner
Super User
537 von 804

@Zuvedi97 

@Plereippeg66 

 

Ich glaube hier liegt ev. ein technisches Missverständnis vor, denn selbstverständlich wird bei Neubauten weiterhin soweit möglich immer direkt FTTH, also Glasfaser verbaut.

Es sind aber mit grosser Sicherheit völlig unumstrittene P2P Erschliessungen und nicht wie ihr vermutlich fälschlicherweise annehmt dezentrale P2MP Erschliessungen.

 

Aus der  Verfügbarkeit von 10 Gbit/sec oder der Verwendung von XGS-PON lässt sich nämlich gar nicht direkt ableiten, dass es sich wirklich um eine dezentrale P2MP-Erschliessung handelt, denn was die Swisscom mit vielen alten und auch neuen P2P-Glasfaserverbindungen macht ist, dass sie diese dann direkt in der Zentrale auf einen optischen Splitter bündelt und dann auf diese Weise als Shared Medium kostengünstiger als P2P-Einzelanschlüsse an den Backbone anschliesst.

 

Weder XGS-PON noch P2MP-Konstrukte generell sind aktuell gestoppt, sondern nur der neue Einbau von dezentralen optischen Splittern, welche dann als Konsequenz alle Provider auf das Swisscom-eigenen P2MP-Konstrukt zwingen und somit die Erreichbarkeit des Kunden mit einer individuellen P2P-Glasfaser verhindern würden.

 

Fazit: Ohne genaue Kenntnis der Architektur der jeweiligen FTTH-Erschliessung lässt sich vom einzelnen Kunden gar nicht erkennen, ob es sich „auf der letzten Meile“ um ein P2P- oder um ein P2MP-Netz handelt.

 

P.S.: Der aktuell grösste Teil von XGS-PON-Anschlüssen mit bis zu 10 Gbit/sec läuft aktuell sowieso auf P2P-Kundenanschlüssen, denn alle Städte, alle Fremdnetze und auch die Swisscom hat bis vor ca. 2 Jahren alle FTTH-Anschlüsse technisch immer als P2P-Anschluss verkabelt, d.h. die nun umstrittenen bereits dezentral eingebauten Splitter ohne Layer 1-Zugang für Swisscom-Abo-Konkurrenten sind also zur Zeit noch recht selten.

 

 

Selbstdeklaration: Emanzipierter Kunde und Hobby-Nerd ohne wirtschaftliche Abhängigkeiten zur Swisscom
Selbstdeklaration: Emanzipierter Kunde und Hobby-Nerd ohne wirtschaftliche Abhängigkeiten zur Swisscom
Editiert
kaetho
Super User
538 von 804

Technisch sicher richtig. Aber interessiert keinen.

Was interessiert: bekomme ich Glas, ja/nein? Wenn ja, wann. Wenn nein, warum nicht? Und da beginnt das Drama.

hed
Level 7
Level 7
539 von 804

@kaetho  schrieb:

Technisch sicher richtig. Aber interessiert keinen.

Was interessiert: bekomme ich Glas, ja/nein? Wenn ja, wann. Wenn nein, warum nicht? Und da beginnt das Drama.


@kaetho 

 

Ein Drama geschieht aktuell anderswo auf der Welt, aber sicher nicht weil ein paar Leute in der Schweiz auf Glas warten müssen, nur weil sie es haben wollen. Ich nenne das Wohlstandsverwahrlosung.

Werner
Super User
540 von 804

@kaetho  schrieb:

Technisch sicher richtig. Aber interessiert keinen.

Was interessiert: bekomme ich Glas, ja/nein? Wenn ja, wann. Wenn nein, warum nicht? Und da beginnt das Drama.


Wenn sowieso genügend Fasern vorhanden sind oder neu verbaut werden, kriegt man auch von der Swisscom aktuell einen neuen Glasfaseranschluss.

 

Kreuzfalsch ist einfach zu meinen Swisscom hätte den Glasfaserausbau generell gestoppt oder aus der Verfügbarkeit von bis zu 10 GBit/sec zwangsweise eine vielleicht momentan „illegale“ P2MP-Erschliessung abzuleiten.

Selbstdeklaration: Emanzipierter Kunde und Hobby-Nerd ohne wirtschaftliche Abhängigkeiten zur Swisscom
Selbstdeklaration: Emanzipierter Kunde und Hobby-Nerd ohne wirtschaftliche Abhängigkeiten zur Swisscom
Nach oben