- Wartungsarbeiten, Nodesplit? Beitrag #51
MrHonk
- BeitrÀge
- 690
- Punkte Reaktionen
- 247
Luftlinie ist aber fĂŒrs Kabel verlegen suboptimal 
Wartungsarbeiten, Nodesplit?
Diskutiere Wartungsarbeiten, Nodesplit? im Netzausbau und Digitalisierung Forum im Bereich Rund um Internet; Luftlinie ist aber fĂŒrs Kabel verlegen suboptimal đ
- Wartungsarbeiten, Nodesplit? Beitrag #52
MartinP_Do
Was ist denn dann Optimal? 525 km?
- Wartungsarbeiten, Nodesplit? Beitrag #53
MrHonk
- BeitrÀge
- 690
- Punkte Reaktionen
- 247
Weder noch ... weder wird man Kabel an Land von Punkt A nach Punkt B auf einer solch langen Strecke in einer schnurgeraden Linie verlegt bekommen, noch wird Kabel immer und ĂŒberall entlang der StraĂen verlegt sein. In der RealitĂ€t wird die Kabelstrecke im Idealfall irgendwo dazwischen liegen.
Ich ging aber ehrlich gesagt auch davon aus, dass mein Smiley am Ende des Beitrags deutlich macht, dass die Antwort nicht so ganz ernst genommen werden sollte.
Ich ging aber ehrlich gesagt auch davon aus, dass mein Smiley am Ende des Beitrags deutlich macht, dass die Antwort nicht so ganz ernst genommen werden sollte.
- Wartungsarbeiten, Nodesplit? Beitrag #54
why_
- BeitrÀge
- 1.723
- Punkte Reaktionen
- 417
- Anbieter
- Unitymedia
Wenn ich mir das gasline Netzwerk (https://www.gasline.de/netz/lwl-backbone/) so angucke wird das wohl Innsbruck -> MĂŒnchen -> Frankfurt laufen und das wĂ€ren realistisch dann eher 550-600 km.
Guckt man sich das via einer RIPE Probe an geht das in 10 ms. Die Latenz via DOCSIS zu meinem ersten Hop ist höher als per Glasfaser von Ăsterreich nach Deutschland. Die Latenz AT -> DE von dem Anschluss ist niedriger als der Jitter den ich auf meiner DOCSIS Leitung habe.
Guckt man sich das via einer RIPE Probe an geht das in 10 ms. Die Latenz via DOCSIS zu meinem ersten Hop ist höher als per Glasfaser von Ăsterreich nach Deutschland. Die Latenz AT -> DE von dem Anschluss ist niedriger als der Jitter den ich auf meiner DOCSIS Leitung habe.
Ich kann es kaum erwarten von DOCSIS weg zu kommen.
Zuletzt bearbeitet:
- Wartungsarbeiten, Nodesplit? Beitrag #55
MartinP_Do
Wenn ich mir das gasline Netzwerk (https://www.gasline.de/netz/lwl-backbone/) so angucke wird das wohl Innsbruck -> MĂŒnchen -> Frankfurt laufen und das wĂ€ren realistisch dann eher 550-600 km.
Guckt man sich das via einer RIPE Probe an geht das in 10 ms. Die Latenz via DOCSIS zu meinem ersten Hop ist höher als per Glasfaser von Ăsterreich nach Deutschland. Die Latenz AT -> DE von dem Anschluss ist niedriger als der Jitter den ich auf meiner DOCSIS Leitung habe.
Ich kann es kaum erwarten von DOCSIS weg zu kommen.
Nunja, bei DOCSIS kommen zu den normalen Laufzeiten anscheinend noch einmal 6...8 ms Latenz hinzu, und das wahrscheinlich auch noch davon abhĂ€ngig, wie ausgelastet der Upload im Segment ist laut untenstehendem Paper kann bei viel Traffic im Segment die Queuing Latenz auch bei 200 ms liegen ... Das schnellte, was ich hier von Dortmund aus mit der Speedtest-App erreiche ist bei Contabo DĂŒsseldorf als Gegenstelle 9 ms ...
Aber auch da gibt es wieder Erweiterungen des DOCSIS Standards ...
https://account.cablelabs.com/server/alfresco/0affb960-25f4-44f9-b747-74ad8555fd06
Die dort gelistete "Queuing-Latency" von 0 ... 200 ms je nach Last ist aber kein Problem von Vodafone - solche Latenzen hat man auch bei Pyur und anderen Kabel-ISPs oder bei einem O2 Internet-Vertrag im Vodafone-Kabelnetz... Die packen aus KostengrĂŒnden auch viele User in ein Segment ...
Ich vermute, dass der Ping sich bei Vodafone DSL-Kunden nicht groĂ von dem anderer DSL-Provider unterscheidet - das heiĂt eigentlich, dass das Kernnetz funktioniert ...
Derzeit liegt hier keine Glasfaser. Ich werde jedenfalls nicht wegen schlechterem Ping zu DSL wechseln... Ich warte auf Glasfaser, und werde dann entscheiden, was ich mache ... Die 45 ⏠an Vodafone sind da schon eine gewisse Schmerzgrenze. Vielleicht noch 15...20 ⏠obendrauf wÀre es mir wert .... Bin kein Gamer, und alles andere funktioniert durchaus zufriedenstellend ...
Derzeit scheint mir mein Segment sogar immer mehr zu verwaisen. Jenseits der mitten durch unser Wohngebiet laufenden HauptstraĂe ist bereits Glasfaser ausgebaut, und einige Power User haben womöglich gewechselt ...
Wenn man wirklich mal das Upstream-Band von 65 auf 200 MHz erweitern wĂŒrde, und nicht den Fehler macht, 400 MBit/s Up zu "verramschen", wird es wahrscheinlich alleine dadurch Verbesserungen geben, weil man womöglich alles in die LL-Queue packen kann...
Zuletzt bearbeitet:
- Wartungsarbeiten, Nodesplit? Beitrag #56
floh667
- BeitrÀge
- 1.879
- Punkte Reaktionen
- 375
1.1.1.1 oder nitrado.de
So wird aber kein LWL verlegt. Die laufen i.d.r entlang Autobahnen oder Strom/Gas trassen.
Edit: ah wurde diesbezĂŒglich ja alles geschrieben. HĂ€tte mal Seite drei vorher angucken sollen
Wenn man ein Testpaket durch die reinen backbones schickt geht das natĂŒrlich super schnell. Erst wenn das eigentliche Docsis Netz dazu kommt, addiert sich da viel Zeit drauf.
In @Edding 's fall war das cmts wahrscheinlich sehr nah und jetzt die Cloud - wo der harmonics Kram drauf lÀuft, irgendwo weiter entfernt.
Zuletzt bearbeitet:
- Wartungsarbeiten, Nodesplit? Beitrag #57
why_
- BeitrÀge
- 1.723
- Punkte Reaktionen
- 417
- Anbieter
- Unitymedia
Latenz und Jitter ging Vodafone bisher am Arsch vorbei und dementsprechend halte ich es fĂŒr Ă€uĂerst unwahrscheinlich das man auch nur ein Mbit fĂŒr bessere Latenzen eintauscht, vor allem da die Konkurrenz jetzt 500 Mbit/s im Upload beim Gigabit Tarif Anbietet.
- Wartungsarbeiten, Nodesplit? Beitrag #58
MrHonk
- BeitrÀge
- 690
- Punkte Reaktionen
- 247
FĂŒr nperf.com, obwohl ich ne Standortfreigabe fĂŒr den Dienst erstellt habe, wohne ich jetzt in Krefeld ... und dabei wohne ich nahezu mittig zwischen Dortmund und MĂŒnster.
Ich wundere mich aber ĂŒber den Unterschied in der gemessenen Geschwindigkeit zwischen der Ookla App und der nperf Webseite. Solche Peaks wurden in der App nicht angezeigt, obwohl die Durchschnittsgeschwindigkeit wieder sehr nah an der von Ookla gemessenen Geschwindigkeit liegt.
Der unterschiedliche Ping kommt ja von der Gegenstelle, wobei ich aber sagen muss, dass die 18 ms liegt deutlich nÀher an der RealitÀt sind als die 8-9 ms der Ookla App.
Pinge ich per Kommandozeile ein Ziel in Frankfurt an, dann schaut das Ergebnis so aus:
Ich wundere mich aber ĂŒber den Unterschied in der gemessenen Geschwindigkeit zwischen der Ookla App und der nperf Webseite. Solche Peaks wurden in der App nicht angezeigt, obwohl die Durchschnittsgeschwindigkeit wieder sehr nah an der von Ookla gemessenen Geschwindigkeit liegt.
Der unterschiedliche Ping kommt ja von der Gegenstelle, wobei ich aber sagen muss, dass die 18 ms liegt deutlich nÀher an der RealitÀt sind als die 8-9 ms der Ookla App.
Pinge ich per Kommandozeile ein Ziel in Frankfurt an, dann schaut das Ergebnis so aus:
Zuletzt bearbeitet:
- Wartungsarbeiten, Nodesplit? Beitrag #59
MartinP_Do
Bei mir :
root@pve:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=16.1 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.9 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=14.2 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=13.3 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=8.19 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=12.6 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=10.9 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=8.53 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=11.3 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=11.1 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=57 time=9.62 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=57 time=11.8 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=57 time=10.5 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=57 time=9.01 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=57 time=7.96 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=57 time=8.75 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=57 time=12.8 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=57 time=12.5 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=57 time=8.86 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=57 time=9.18 ms
^C
--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19025ms
rtt min/avg/max/mdev = 7.962/10.955/16.058/2.159 ms
root@pve:~#
Wenn Du an einem Harmonics vCMTS hĂ€ngst, wĂ€ren solche Standorte durchaus möglich, da ein Server in einem lokalen Datacenter immer bis zu zehn von den vCMTS steuert... ist aber auch immer etwas ungenau, die lokalisierung ĂŒber die IP-Adresse ... Statt Dortmund wird bei mir "Kerpen" angezeigt fĂŒr die IPv4... mit einer IPv6 aus meinem Range bin ich in jetzt in Stuttgart ...
root@pve:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=16.1 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.9 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=14.2 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=13.3 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=8.19 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=12.6 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=10.9 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=8.53 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=11.3 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=11.1 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=57 time=9.62 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=57 time=11.8 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=57 time=10.5 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=57 time=9.01 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=57 time=7.96 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=57 time=8.75 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=57 time=12.8 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=57 time=12.5 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=57 time=8.86 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=57 time=9.18 ms
^C
--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19025ms
rtt min/avg/max/mdev = 7.962/10.955/16.058/2.159 ms
root@pve:~#
Wenn Du an einem Harmonics vCMTS hĂ€ngst, wĂ€ren solche Standorte durchaus möglich, da ein Server in einem lokalen Datacenter immer bis zu zehn von den vCMTS steuert... ist aber auch immer etwas ungenau, die lokalisierung ĂŒber die IP-Adresse ... Statt Dortmund wird bei mir "Kerpen" angezeigt fĂŒr die IPv4... mit einer IPv6 aus meinem Range bin ich in jetzt in Stuttgart ...
- Wartungsarbeiten, Nodesplit? Beitrag #60
Edding
- BeitrÀge
- 1.694
- Punkte Reaktionen
- 187
- Anbieter
- Unitymedia
So sah das vorher bei mir auch aus, sogar noch etwas niedriger....
Code:
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=25.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=18.0 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=18.5 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=14.1 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=15.3 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=12.8 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=14.3 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=14.8 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=21.5 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=16.6 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=15.8 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=13.6 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=20.1 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=13.3 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=15.5 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=13.9 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=15.3 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=11.9 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=22.9 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=14.0 ms
64 bytes from 1.1.1.1: icmp_seq=21 ttl=58 time=12.7 ms
64 bytes from 1.1.1.1: icmp_seq=22 ttl=58 time=12.5 ms
64 bytes from 1.1.1.1: icmp_seq=23 ttl=58 time=23.7 ms
64 bytes from 1.1.1.1: icmp_seq=24 ttl=58 time=13.6 ms
64 bytes from 1.1.1.1: icmp_seq=25 ttl=58 time=23.6 ms
64 bytes from 1.1.1.1: icmp_seq=26 ttl=58 time=21.6 ms
64 bytes from 1.1.1.1: icmp_seq=27 ttl=58 time=12.2 ms
64 bytes from 1.1.1.1: icmp_seq=28 ttl=58 time=20.2 ms
64 bytes from 1.1.1.1: icmp_seq=29 ttl=58 time=17.9 ms
64 bytes from 1.1.1.1: icmp_seq=30 ttl=58 time=20.4 ms
64 bytes from 1.1.1.1: icmp_seq=31 ttl=58 time=14.6 ms
64 bytes from 1.1.1.1: icmp_seq=32 ttl=58 time=22.3 ms
64 bytes from 1.1.1.1: icmp_seq=33 ttl=58 time=21.7 ms
64 bytes from 1.1.1.1: icmp_seq=34 ttl=58 time=10.6 ms- Wartungsarbeiten, Nodesplit? Beitrag #61
MartinP_Do
Geht deutlich mehr "rauf und runter" bei Dir - mehr Jitter...
Deutet auf ein stĂ€rker ĂŒberlastetes Segment hin (lĂ€ngere Wartezeiten in der Upstream Queue auf einen freie Timeslot)
Erste Messung bei Mir
rtt min/avg/max/mdev = 7.962/10.955/16.058/2.159 ms
aktuell
rtt min/avg/max/mdev = 7.838/10.769/17.588/2.293 ms
Der "Jitter Schlauch" ist etwas breiter geworden, die Leute haben langsam Feierabend und kommen nach Hause ...
Deutet auf ein stĂ€rker ĂŒberlastetes Segment hin (lĂ€ngere Wartezeiten in der Upstream Queue auf einen freie Timeslot)
Erste Messung bei Mir
rtt min/avg/max/mdev = 7.962/10.955/16.058/2.159 ms
aktuell
rtt min/avg/max/mdev = 7.838/10.769/17.588/2.293 ms
Der "Jitter Schlauch" ist etwas breiter geworden, die Leute haben langsam Feierabend und kommen nach Hause ...
- Wartungsarbeiten, Nodesplit? Beitrag #62
why_
- BeitrÀge
- 1.723
- Punkte Reaktionen
- 417
- Anbieter
- Unitymedia
Oder das CMTS idled stĂ€rker und durch die niedriger taktene CPU ist die Latenz höher, oder es sind einfach mehr CPEs in dem Segment. Ich zweifele jedenfalls deine Deutung an da sich Latenz und Jitter durch einen CMTS tausch dann nicht Ă€ndern dĂŒrften.
- Wartungsarbeiten, Nodesplit? Beitrag #63
MartinP_Do
Was ist der Unterschied zwischen "mehr CPEs im Segment" und "stĂ€rker ĂŒberlastetes Segment"?
Sehr wahrscheinlich kann sich die Latenz auch durch einen CMTS-Herstellerwechsel bei unverĂ€nderter Segmentlast Ă€ndern. Die Feinheiten der Implementierung des Queue - Handling Algorithmus zur Zuweisung von Upload-Zeitschlitzen fĂŒr die einzelnen CPEs ist wahrscheinlich etwas, was die Hersteller nur unter Folter herausgeben wĂŒrden ... jedenfalls kein StĂŒck Standard-Software...
Daneben ist die Frage, ob es auch vorher in dem Segment schon TaFDM gegeben hat ... mir scheint das Umschalten in Zeitschlitzen zwischen DOCSIS 3.0 und DOCSIS 3.1 Modulation auf den gleichen Frequenzen womöglich auch fĂŒr etwas mehr Latenz zu sorgen...
Ein weiterer Punkt ist wahrscheinlich die Interpretation des Konzepts der vCMTS durch Vodafone ...
Empfohlen wird eine maximale GlasfaserlÀnge vom Datacenter bis zum Remote Phy von 70 km, dass die IP-Verbindung quasi Jitter-Frei ist, und dass auf einem Virtualisierungsserver im Datacenter maximal zehn vCMTS gerechnet werden ...
Wer weiĂ wie Vodafone diese Empfehlungen im Zweifelsfall beherzigt ...
Dieses Virtualisierungskonzept bedeutet daneben auch, dass die Ănderungsgefahr gröĂer ist.
Wenn fĂŒr mein Segment aktuell ein Virtualisierungsserver zustĂ€ndig ist, der z. B. erst 7 vCMTS zu bearbeiten hat, wĂŒrde das vielleicht die bessere Situation bei mir erklĂ€ren... das kann sich aber jederzeit Ă€ndern, wenn da noch 2...3 vCMTS mehr aufgeschaltet werden ...
- Wartungsarbeiten, Nodesplit? Beitrag #64
why_
- BeitrÀge
- 1.723
- Punkte Reaktionen
- 417
- Anbieter
- Unitymedia
Ist ein Segment ĂŒberlastet nur weil da 1000 CPEs drin idlen?
- Wartungsarbeiten, Nodesplit? Beitrag #65
floh667
- BeitrÀge
- 1.879
- Punkte Reaktionen
- 375
wenn man sich den Unterschied mal anschaut. @MrHonk sitzt in Dortmund und hat via StraĂen 525km nach berlin. Sein Ergebnis sieht man oben.
Mein Anschluss ist in Kehl Ortsteil, sĂŒdwestliches BaWĂŒ, klassisches Arris CMTS in Offenburg (15km entfernt von hier) und ĂŒber 700km entfernt von Berlin
Mein Anschluss ist in Kehl Ortsteil, sĂŒdwestliches BaWĂŒ, klassisches Arris CMTS in Offenburg (15km entfernt von hier) und ĂŒber 700km entfernt von Berlin
- Wartungsarbeiten, Nodesplit? Beitrag #66
Edding
- BeitrÀge
- 1.694
- Punkte Reaktionen
- 187
- Anbieter
- Unitymedia
- Wartungsarbeiten, Nodesplit? Beitrag #67
MrHonk
- BeitrÀge
- 690
- Punkte Reaktionen
- 247
Urgs, die Werte schauen wirklich nicht so dolle aus.
Hier mal zum Vergleich ne aktuelle Messung von meinem Standort aus
Immerhin packt der Speedtest mich jetzt nÀher ans reale Zuhause, auch wenn Dortmund noch ca. 45 km von mir entfernt liegt, so ist es doch deutlich nÀher als Kassel von heute Mittag.
Achso, kleiner Nachtrag: auf ĂŒber 1 Gb/s komme ich auch nur, weil meine PCs alle per 10Gb Glasfaser miteinander verbunden sind und der 10G-Switch am 2,5G Port der 6690 hĂ€ngt.
Hier mal zum Vergleich ne aktuelle Messung von meinem Standort aus
Immerhin packt der Speedtest mich jetzt nÀher ans reale Zuhause, auch wenn Dortmund noch ca. 45 km von mir entfernt liegt, so ist es doch deutlich nÀher als Kassel von heute Mittag.
Achso, kleiner Nachtrag: auf ĂŒber 1 Gb/s komme ich auch nur, weil meine PCs alle per 10Gb Glasfaser miteinander verbunden sind und der 10G-Switch am 2,5G Port der 6690 hĂ€ngt.
Zuletzt bearbeitet:
- Wartungsarbeiten, Nodesplit? Beitrag #68
MartinP_Do
- Wartungsarbeiten, Nodesplit? Beitrag #69
floh667
- BeitrÀge
- 1.879
- Punkte Reaktionen
- 375
@Edding was sagt der test? https://www.geschwindigkeit.de/ping-test/
- Wartungsarbeiten, Nodesplit? Beitrag #70
Edding
- BeitrÀge
- 1.694
- Punkte Reaktionen
- 187
- Anbieter
- Unitymedia
- Wartungsarbeiten, Nodesplit? Beitrag #71
floh667
- BeitrÀge
- 1.879
- Punkte Reaktionen
- 375
sieht grauenhaft aus. Aber die 50mbit im upstream kommen an?
- Wartungsarbeiten, Nodesplit? Beitrag #72
Edding
- BeitrÀge
- 1.694
- Punkte Reaktionen
- 187
- Anbieter
- Unitymedia
TagsĂŒber Ja aber Abends nicht mehr...
- Wartungsarbeiten, Nodesplit? Beitrag #73
MartinP_Do
Wenn das "grauenhaft" aussieht - wie sieht denn ein guter Ping aus?
Der Jitter ist deutlich höher, als bei mit (2,1 ms), aber der "average" liegt auch bei 16 ms ...
https://www.geschwindigkeit.de/ping-test/202424-176355-e477.html
Der hier ist auch interessant ...
Standardeinstellungen belassen bis auf...
- Server auf "Deutschland" eingestellt
- Testdauer 120 Sekunden...
https://de.packetlosstest.com/
Auf dieser Seite fÀngt "Grauenhaft" wohl deutlich spÀter an, als bei Euch, wenn man sich das durchliest, was da als Interpretationshilfe erscheint, wenn man "ist das ein gutes Ergebnis" anklickt ;-)
Jedenfalls wĂ€re der AusreiĂer auf ca 235 ms Ausschlusskriterium fĂŒr Egoshooter ...
Zuletzt bearbeitet:
- Wartungsarbeiten, Nodesplit? Beitrag #74
articfox
- BeitrÀge
- 1.643
- Punkte Reaktionen
- 54
- Anbieter
- Unitymedia
Und schon wieder sind Wartungsarbeiten in kĂŒrzester Zeit geplant.
Nachjustierung?
Wann? Am 04.07.2024 zwischen 07:00 und 10:00 Uhr
Es kann zu EinschrÀnkungen oder AusfÀllen Ihrer Services kommen
â allerdings höchstens 10 Minuten.
Nachjustierung?
Wann? Am 04.07.2024 zwischen 07:00 und 10:00 Uhr
Es kann zu EinschrÀnkungen oder AusfÀllen Ihrer Services kommen
â allerdings höchstens 10 Minuten.
- Wartungsarbeiten, Nodesplit? Beitrag #75
MartinP_Do
man kann aber leider in einem einigermaĂen frequentierten Segment nicht besonders viel in Richtung "weniger Jitter" machen... Der Time-Division-Multiplex im Upload ist da schon ein stĂ€rkerer Flaschenhals, als bei anderen Technologien ...
Das ist aber erstmal kein Vodafone-Problem, sondern ein Problem der Technologie ... Glasfaser und DSL haben da den Vorteil, dass man da, wo Zeitschlitze problematisch werden können nach dem Motto "viel hilft viel" arbeiten kann...
Vodafone verschÀrft das Problem aber wahrscheinlich dadurch, dass es ungesund viele Teilnehmer pro Segment gibt ...
Abhilfe können hier nur kleinere Segmente und eine Erhöhung des fĂŒr Upload bereitgestellten Frequenzbereiches bringen. Das wird man aber sicherlich kostentechnisch mit klassischen CMTS nicht darstellen können ...
Vielleicht kriegt man ja auch die Harmonic vCMTS noch verbessert. Vielleicht besteht das Nachjustieren im Einspielen eines Firmware-Updates in den Remote-Phy ;-)
Das ist aber erstmal kein Vodafone-Problem, sondern ein Problem der Technologie ... Glasfaser und DSL haben da den Vorteil, dass man da, wo Zeitschlitze problematisch werden können nach dem Motto "viel hilft viel" arbeiten kann...
Vodafone verschÀrft das Problem aber wahrscheinlich dadurch, dass es ungesund viele Teilnehmer pro Segment gibt ...
Abhilfe können hier nur kleinere Segmente und eine Erhöhung des fĂŒr Upload bereitgestellten Frequenzbereiches bringen. Das wird man aber sicherlich kostentechnisch mit klassischen CMTS nicht darstellen können ...
Vielleicht kriegt man ja auch die Harmonic vCMTS noch verbessert. Vielleicht besteht das Nachjustieren im Einspielen eines Firmware-Updates in den Remote-Phy ;-)
Thema: