Mit etwas neuer Motivation hängt der Router nun indoor, aber unterm Dach. SQM weiterhin manuell an die Situation angepasst
Ist das Festnetz oder LTE/5G? Dann waere vielleicht cake-autorate das Mittel der Wahl... fuer den Mobilfunklink.
Mit etwas neuer Motivation hängt der Router nun indoor, aber unterm Dach. SQM weiterhin manuell an die Situation angepasst
Ist das Festnetz oder LTE/5G? Dann waere vielleicht cake-autorate das Mittel der Wahl... fuer den Mobilfunklink.
Passend zum Thread Mobilfunk.
Und ja, das Skript habe ich mir mal angesehen. Tatsächlich ist bei uns der Durchsatz aber sehr stabil.
Mal ein kleines Update nach einigen Wochen Betrieb.
Der DSL-Anschluss ist mittlerweile komplett außer Betrieb. Die letzte Rufnummer, die ich noch "nutzen" möchte (erreichbar sein), ist zu Fonial portiert. Auch in Vorbereitung zum kommenden FTTH-Anschluss, dessen Umsetzung nun hoffentlich in den letzten Zügen liegt. Der ONT ist installiert und ich weiß, dass einzelne Anschlüsse wohl schon tatsächlich im Ort im Betrieb sind.
Wie sieht es inzwischen im Alltag mit dem 5G-Router aus? Recht gut, möchte ich sagen. Die Bandbreite ist recht stabil bei mindestens 500/100. Im Download oft auch bis 750 Mbps.
Live gezogen (wobei Sonntagmorgen ggf. wenig repräsentativ ist):
Speedtest by Ookla
Server: Deutsche Telekom - Dusseldorf (id: 30906)
ISP: Deutsche Telekom AG
Idle Latency: 14.98 ms (jitter: 0.03ms, low: 14.97ms, high: 15.01ms)
Download: 759.25 Mbps (data used: 995.9 MB)
91.74 ms (jitter: 23.46ms, low: 17.97ms, high: 172.18ms)
Upload: 104.39 Mbps (data used: 116.3 MB)
26.95 ms (jitter: 4.41ms, low: 19.29ms, high: 53.98ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/218b1230-2f58-43b6-a77a-1182e2595958
Alles anzeigen
"Spürbar" sind hier und da vielleicht die längeren Laufzeiten. Wobei auch das eher homöopathisch ist.
Hier mal eine Statistik zu 8.8.8.8:
--- 8.8.8.8 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 49593ms
rtt min/avg/max/mdev = 14.131/19.935/43.097/6.336 ms
Auch nicht schlechter als der Kabelzugang vor ein paar Jahren. DSL war hier aber konstanter und schneller, mit 8-9 ms.
Vielleicht meine ich das in Onlinespielen zu spüren.
Die allgemeine Stabilität konnte ich mit eurer Hilfe hier ja verbessern. Da gab es noch ein Problem beim DHCP-Renewal, was nur sporadisch auftrat, wenn tatsächlich die Verbindung nach Tagen oder Wochen neu hergestellt wurde. Aber auch das ist jetzt gelöst.
Aktuell ist die SIM-Karte seit 12 Tagen eingeloggt und die öffentliche und routbare IPv4-Adresse seither stabil. Ansonsten ist die Lease-Time nun bei 10 Minuten von mir manuell festgelegt worden. Das klappt ohne weitere Probleme.
Finanziell ist das Ganze ohnehin gerade ein No-Brainer. Die Multi-SIM kostet 5 €/Monat und bietet mir das selbe Volumen meiner Haupt-SIM, sprich unbegrenzt. Das ist in der Tat das größte Problem, was ich aufziehen kommen sehe.
FTTH wird mich mit 500/250 Mbps 65 € kosten (fairerweise ist dort Telefonie flat enthalten).
4G/5G mit (aktuell) 500/100 Mbps hingegen nur 5 €/Monat. Wobei hoffentlich Upload, Geschwindigkeit und allgemeine Stabilität eher bei FTTH besser sein werden. Unklar bleibt der Backbone - das ist bei net services für mich eine große Unbekannte.
Das ist mit Sicherheit keine allgemein gültige Betrachtung. Mobilfunk hängt massiv vom lokalen Ausbau und der sonstigen Nutzung dort ab. Im Ort gibt es bei uns sicherlich nur wenige, die hybride Anschlüsse oder reine Mobilfunkanschlüsse zu Hause nutzen.
Mindestens das Thema Backup über DSL oder Kabel ist bei mir aber sehr weit in der Hintergrund gerückt.
Unklar bleibt der Backbone - das ist bei net services für mich eine große Unbekannte.
Wenn das http://www.netservices.de/ sind haben die einen eigenen BB.
Netservices hat folgende Provider:
AS3356 (Lumen/Level3)
AS174 (Cogent)
AS37468 (Angola-Cables) (nur )
und peert am DE-CIX (wohl nur IPv6) (100G in FFM, 40G in HH)
und peert mit AS6461 (Zayo)
Das sieht fuer mich jetzt nicht erkennbar problematisch aus... (Cogent Multi-Homed ist so weit ich weiss OK)
Level 3 ist auch sehr gut. Lange im Geschäft mit dicken Backbone.
Wenn das http://www.netservices.de/ sind haben die einen eigenen BB.
Interessant, vorher stammt der traceroute?
Alles anzeigenNetservices hat folgende Provider:
AS3356 (Lumen/Level3)
AS174 (Cogent)
AS37468 (Angola-Cables) (nur )
und peert am DE-CIX (wohl nur IPv6) (100G in FFM, 40G in HH)
und peert mit AS6461 (Zayo)
Das sieht fuer mich jetzt nicht erkennbar problematisch aus... (Cogent Multi-Homed ist so weit ich weiss OK)
Danke, das hatte ich mir auch schon mal grob angesehen. Auch wie viele IPv4-Adressen die so besitzen (die Umstellung kostet einmalig 20 €, was ok ist).
Aber da würde ich immer erstmal eigene Erfahrung abwarten wollen.
Netservices hat folgende Provider:
AS37468 (Angola-Cables) (nur )
Die kannst du streichen, die stehen, wenn man unser AS bei qrator eingibt auch als angeblicher Upstreamprovider drin. Haben wir aber nicht.
und peert am DE-CIX (wohl nur IPv6) (100G in FFM, 40G in HH)
HH wird via GlobePeer Remote angebunden sein, machen wir auch so mit DUS, HH und MUC.
Ah, BGP.tools listet auch nur Level3 und Cogent als Upstreams (AS37468 nur als Peer)
HH wird via GlobePeer Remote angebunden sein, machen wir auch so mit DUS, HH und MUC.
Kannst du aus deiner Sicht mal die Differenzierung bzw. den Vorteil benennen? Das klingt für mich so, als ob das Netzwerk physikalisch nur in z.B. FFM angeschlossen ist und man via VLAN im Backbone von DE-CIX auch in HH peeren kann.
Kannst du aus deiner Sicht mal die Differenzierung bzw. den Vorteil benennen? Das klingt für mich so, als ob das Netzwerk physikalisch nur in z.B. FFM angeschlossen ist und man via VLAN im Backbone von DE-CIX auch in HH peeren kann.
Exakt so ist es.
Frage, taucht FFM da in traceroutes zu Zielen in HH auf, oder wird das alles so getunnelt, dass der "Umweg" ueber FFM auf L3 gar nicht sichtbar wird?
Exakt so ist es.
Der Vorteil ist also, dass man in HH mit Netzen peeren kann, die in FFM keine Konnketivität haben?
Dadurch spart sich der Anbieter die Leitung und den Port in HH, nehme ich an.
Praktisch wird es die Latenz etwas hochtreiben, da das Paket physikalisch immer erstmal nach FFM geswitcht wird, bevor es dann nach HH weitergeht. Das wird schon ein paar ms ausmachen, oder?
Konrekt sind es von hier aus Luftlinie 250 km nach FFM und 150 km nach HH. Angenommen, die Alternative wäre, dass mein Anbieter regionale Knoten hätte und die Strecke nach HH optimal angebunden sei. Dann wäre der Umweg bei 250+400+400+250 = 1300 km hin und zurück. Bei direkter Anbindung 150+150 = 300 km hin und zurück. Mir ist natürlich klar, dass die Annahme Luftlinie stark vereinfacht ist. Aber die 1000 km extra machen ca. 5 ms aus, ohne zusätzliche Verluste durch (VLAN)-Switching.
Die Relevanz ist natürlich überschaubar.
Frage, taucht FFM da in traceroutes zu Zielen in HH auf, oder wird das alles so getunnelt, dass der "Umweg" ueber FFM auf L3 gar nicht sichtbar wird?
Dem Trace in RE: Kleiner Erfahrungsbericht zum 5G-Router Zyxel NR7302 nach taucht im L3 nur HH auf.
DIe Daumenregel ist: 1 Millisekunde RTT reichen fuer 100 Km Signallaufzeit in Glasfaser (also hin und zurueck), wobei aktive Netzwerk-Hops oft selber noch ein paar Millisekunden zusaetzlich benoetigen. D.h. 1000 km machen etwa 10 Millisekunden RTT aus.
Bei O2 sehe ich i.d.R. etwa 8-9 ms von Hamburg/Ahrensburg nach Frankfurt am Main/Offenbach, ich weiss aber nicht wie die Kabelstrecken da genau verlaufen, also wie lang der eigentliche Weg ist..
Frage, taucht FFM da in traceroutes zu Zielen in HH auf, oder wird das alles so getunnelt, dass der "Umweg" ueber FFM auf L3 gar nicht sichtbar wird?
Nein, das ist ein anderes VLAN.
DIe Daumenregel ist: 1 Millisekunde RTT reichen fuer 100 Km Signallaufzeit in Glasfaser (also hin und zurueck), wobei aktive Netzwerk-Hops oft selber noch ein paar Millisekunden zusaetzlich benoetigen. D.h. 1000 km machen etwa 10 Millisekunden RTT aus.
Bei O2 sehe ich i.d.R. etwa 8-9 ms von Hamburg/Ahrensburg nach Frankfurt am Main/Offenbach, ich weiss aber nicht wie die Kabelstrecken da genau verlaufen, also wie lang der eigentliche Weg ist..
Nun ja, da ist es natürlich interessant, wie gemessen wird, getreu dem alten Spruch: wer misst, misst Mist.
10 ms RTT für 1000 km berücksichtigt keinerlei aktive Netzwerkkomponenten (oder nur ganz wenige und optimierte Komponenten).
Meine Messungen über eine beleuchtete Darkfiberstrecke von knapp 20 km zwischen zwei Adva Multiplexern, danach zwei Cisco-Switches und 2 Dell PowerEdge Servern (MS Windos Server als OS) mit Intel X-710 (aktive CNAs), Messsoftware: nuttcp-8.1.4.exe (Messdauer 7 Tage, eine Messung pro Minute), zeigen mir eine RTT von 0,52 ms (Standardabweichung: 0,06). Die Windowsserver hatten in dem Zeitfenster keine zusätzliche Aufgabe, waren also keine Game-Server, AD-Controller, Exchange, o.ä.
Das nur mal als Anhaltspunkt. Für synchronen Storage über eine WAN-Strecke, die nach Herstellerangaben eine maximal RTT von 10 ms haben darf, gelten 60 km Gf-Länge (einfache Strecke) als Maximum für den stabilen Betrieb. Für diejenigen die mit DORA zu tun haben, bedeutet dies natürlich, das Storage nur asynchron gespiegelt/repliziert werden kann, um den Anforderungen nachzukommen.
10 ms RTT für 1000 km berücksichtigt keinerlei aktive Netzwerkkomponenten (oder nur ganz wenige und optimierte Komponenten).
Volle Zustimmung, ich hatte versucht das mit "wobei aktive Netzwerk-Hops oft selber noch ein paar Millisekunden zusaetzlich benoetigen" zu beschreiben.
Meine Messungen über eine beleuchtete Darkfiberstrecke von knapp 20 km zwischen zwei Adva Multiplexern, danach zwei Cisco-Switches und 2 Dell PowerEdge Servern (MS Windos Server als OS) mit Intel X-710 (aktive CNAs), Messsoftware: nuttcp-8.1.4.exe (Messdauer 7 Tage, eine Messung pro Minute), zeigen mir eine RTT von 0,52 ms (Standardabweichung: 0,06). Die Windowsserver hatten in dem Zeitfenster keine zusätzliche Aufgabe, waren also keine Game-Server, AD-Controller, Exchange, o.ä.
Selbst in einen (Kupfer-LAN) ueber eine direkte Verbindung ist es IMHO schwer ICMP echo/request ("Ping") mit weniger als 0.5 ms zu messen...
Als grobes Schaetzeisen wie weit entfernt ein antwortendes Netz-Element sich befinden kann ist die Daumenregel IMHO ganz brauchbar, aber genaue Netztopologie kann man damit eher nicht messen/triangulieren ![]()
Wenn das http://www.netservices.de/ sind haben die einen eigenen BB.
Wobei ich daraus noch nicht ganz schlau werde.
Wir sehen, dass 1.1.1.1 am DE-CIX in HH bedient wird. Die Latenz lässt für mich keinen anderen Schluss zu, oder (keine Differenz zwischen 4 und 5)?
Der Sprung auf 6 ms erfolgt aber bereits im ersten Hop/L3. Wenn der nicht in/um HH sein sollte, sondern zentral über FFM angebunden, ergibt das für mich keinen Sinn. Wenn dem so wäre, würde ich zwischen Hop 3 und 4 einen größeren Sprung erwarten.
Oder übersehe ich etwas?