Drosselung bei Vodafone West (Aorta-Backbone)?

Internet und Telefon gestört oder gar ganz ausgefallen? Speedprobleme, die nicht offensichtlich auf die verwendeten Geräte zurückzuführen sind? Dann ist dieses Forum genau richtig!
Forumsregeln
Forenregeln


Bitte gib bei der Erstellung eines Threads im Feld „Präfix“ an, ob du Kunde von Vodafone Kabel Deutschland („[VFKD]“), von Vodafone West („[VF West]“), von eazy („[eazy]“) oder von O2 über Kabel („[O2]“) bist.
maffle
Newbie
Beiträge: 55
Registriert: 01.01.2016, 01:53

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von maffle »

So, doch nich ins Bett, noch mal alles neu diesmal mit iperf2:

iperf2 udp test von mir zum VPS server:

[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 5.38 MBytes 45.1 Mbits/sec 689
[ 5] 1.00-2.00 sec 5.98 MBytes 50.2 Mbits/sec 766
[ 5] 2.00-3.00 sec 5.94 MBytes 49.8 Mbits/sec 760
[ 5] 3.00-4.00 sec 5.95 MBytes 49.9 Mbits/sec 762
[ 5] 4.00-5.00 sec 5.98 MBytes 50.1 Mbits/sec 765
[ 5] 5.00-6.00 sec 5.95 MBytes 49.9 Mbits/sec 762
[ 5] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 10.00-10.08 sec 616 KBytes 65.8 Mbits/sec 77
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag rams
[ 5] 0.00-10.08 sec 59.6 MBytes 49.6 Mbits/sec 0.000 ms 0/7633 (0%)

iperf2 udp test von meinem VPS server zu mir, erst mit 10mbit, dann 100, dann 200, dann 500:

iperf -c IP -u -i 1 -b 10M
iperf -c IP -u -i 1 -b 20M
iperf -c IP -u -i 1 -b 100M
iperf -c IP -u -i 1 -b 500M

Server listening on UDP port 580**
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 42866
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 2.0 sec 2.50 MBytes 10.5 Mbits/sec 0.080 ms 0/ 1786 (0%)
[ 3] 2.0- 4.0 sec 2.50 MBytes 10.5 Mbits/sec 0.100 ms 0/ 1784 (0%)
[ 3] 4.0- 6.0 sec 2.50 MBytes 10.5 Mbits/sec 0.087 ms 0/ 1783 (0%)
[ 3] 6.0- 8.0 sec 2.50 MBytes 10.5 Mbits/sec 0.097 ms 0/ 1784 (0%)
[ 3] 0.0-10.0 sec 12.5 MBytes 10.5 Mbits/sec 0.129 ms 2147465812/2147474730 (1e+02%)
[ 4] local 10.0.0.9 port 580** connected with 94.16.123.* port 60515
[ 4] 0.0- 2.0 sec 25.0 MBytes 105 Mbits/sec 0.146 ms 0/17843 (0%)
[ 4] 2.0- 4.0 sec 24.9 MBytes 105 Mbits/sec 0.313 ms 0/17791 (0%)
[ 4] 4.0- 6.0 sec 25.0 MBytes 105 Mbits/sec 0.135 ms 6/17827 (0.034%)
[ 4] 6.0- 8.0 sec 25.0 MBytes 105 Mbits/sec 0.133 ms 0/17831 (0%)
[ 4] 0.0-10.0 sec 125 MBytes 105 Mbits/sec 0.097 ms 2147305326/2147394482 (1e+02%)
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 60246
[ 3] 0.0- 2.0 sec 49.9 MBytes 209 Mbits/sec 0.181 ms 36/35629 (0.1%)
[ 3] 2.0- 4.0 sec 49.8 MBytes 209 Mbits/sec 0.024 ms 354/35519 (1%)
[ 3] 2.00-4.00 sec 354 datagrams received out-of-order
[ 3] 4.0- 6.0 sec 50.1 MBytes 210 Mbits/sec 0.069 ms 7/35759 (0.02%)
[ 3] 6.0- 8.0 sec 49.9 MBytes 209 Mbits/sec 0.188 ms 2/35583 (0.0056%)
[ 3] 6.00-8.00 sec 79 datagrams received out-of-order
[ 3] 0.0-10.0 sec 250 MBytes 210 Mbits/sec 0.055 ms 2147127033/2147305318 (1e+02%)
[ 3] 0.00-10.00 sec 433 datagrams received out-of-order
[ 4] local 10.0.0.9 port 580** connected with 94.16.123.* port 49247
[ 4] 0.0- 2.0 sec 104 MBytes 437 Mbits/sec 0.032 ms 13116/87461 (15%)
[ 4] 2.0- 4.0 sec 104 MBytes 435 Mbits/sec 1.523 ms 15136/89170 (17%)
[ 4] 4.0- 6.0 sec 103 MBytes 433 Mbits/sec 0.683 ms 15601/89168 (17%)
[ 4] 6.0- 8.0 sec 102 MBytes 427 Mbits/sec 0.024 ms 16009/88677 (18%)
[ 4] 8.0-10.0 sec 103 MBytes 432 Mbits/sec 1.652 ms 16212/89606 (18%)
[ 4] 0.0-10.0 sec 516 MBytes 432 Mbits/sec 1.552 ms 2146671556/2147039565 (1e+02%)

Ich weiß nicht was die ca 17% packet loss bei dem 500mbit test aussagen, aber die kamen hier an, sah ich auch am task manager dass ich von mir mit 500mibt gezogen hab auf dem LAN interface. Hatte gelesen dass auch bei iperf2 die UDP packet loss Anzeige nicht sehr verlässlich sein kann.

Über http download von dem selben VPS server selbes problem, es fängt schnell an aber nicht sehr schnell, um die 20mb/s, sackt dann auf ca 10mb/s ab.

Die route ist komischerweise anders vom VPS zu mir, als von mir zum VPS:

Vom VPS zu mir:

Host Loss% Snt Last Avg Best Wrst StDev
1. 94.16.120.3 0.0% 70 3.1 3.4 0.3 67.5 13.0
2. ae3-4018.bbr01.anx84.nue.de.anex 0.0% 70 0.4 2.1 0.4 34.4 5.3
3. ae2-0.bbr02.anx25.fra.de.anexia- 0.0% 70 4.5 4.2 3.8 8.2 0.6
4. ae0-0.bbr01.anx25.fra.de.anexia- 0.0% 70 16.3 4.8 3.6 44.8 5.2
5. de-fra02a-ri1-ae-8-1337.aorta.ne 0.0% 70 6.5 3.9 3.6 10.8 1.0
6. de-fra01b-rc1-ae-56-0.aorta.net 0.0% 70 12.3 10.7 10.0 13.3 0.9
7. de-gek01a-rd02-ae-1-0.aorta.net 0.0% 69 10.0 10.6 9.9 29.3 2.4
8. ???
9. ip-84-118-*-*.unity-media.net 0.0% 69 17.3 19.0 16.9 23.9 1.6

Von mir zum VPS:

1 <1 ms <1 ms <1 ms wrtarm.lan [10.0.0.199]
2 2 ms 2 ms 2 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
4 11 ms 10 ms 9 ms de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net [81.210.139.10]
5 18 ms 17 ms 19 ms de-fra01b-rc1-ae-7-0.aorta.net [84.116.197.50]
6 19 ms 15 ms 26 ms de-fra02a-ri1-ae-0-0.aorta.net [84.116.137.34]
7 15 ms 15 ms 15 ms 213.46.179.114.aorta.net [213.46.179.114]
8 19 ms 21 ms 19 ms ae0-0.bbr02.anx25.fra.de.anexia-it.net [144.208.208.142]
9 19 ms 17 ms 17 ms ae1-0.bbr01.anx84.nue.de.anexia-it.net [144.208.208.140]
10 17 ms 19 ms 19 ms netcup-gw.bbr01.anx84.nue.de.anexia-it.net [144.208.211.31]
11 18 ms 19 ms 17 ms v2201801570**.hotsrv.de [94.16.***.**]

Wieso ist vom VPS zu mir der letzte hop de-gek01a-rd02-ae-1-0.aorta.net und von mir weg jedoch de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net ?

----

Noch mal gestaffelt zu mir, 500, 400, 300, 200, 100 udp:

C:\Programme (frei)\iperf-2.0.9-win64>iperf -s -i 2 -u -p 580**
------------------------------------------------------------
Server listening on UDP port 580**
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 33405
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 2.0 sec 97.3 MBytes 408 Mbits/sec 0.030 ms 17336/86725 (20%)
[ 3] 2.0- 4.0 sec 97.6 MBytes 410 Mbits/sec 0.159 ms 19265/88918 (22%)
[ 3] 4.0- 6.0 sec 96.2 MBytes 404 Mbits/sec 0.009 ms 21262/89891 (24%)
[ 3] 4.00-6.00 sec 162 datagrams received out-of-order
[ 3] 6.0- 8.0 sec 98.2 MBytes 412 Mbits/sec 0.024 ms 18937/88991 (21%)
[ 3] 6.00-8.00 sec 1080 datagrams received out-of-order
[ 3] 8.0-10.0 sec 100 MBytes 420 Mbits/sec 0.073 ms 17395/88802 (20%)
[ 3] 8.00-10.00 sec 2056 datagrams received out-of-order
[ 3] 0.0-10.0 sec 491 MBytes 411 Mbits/sec 0.061 ms 2146689089/2147039271 (1e+02%)
[ 3] 0.00-10.02 sec 3298 datagrams received out-of-order
[ 4] local 10.0.0.9 port 580** connected with 94.16.123.* port 34192
[ 4] 0.0- 2.0 sec 89.3 MBytes 374 Mbits/sec 0.327 ms 5619/69292 (8.1%)
[ 4] 2.0- 4.0 sec 92.9 MBytes 390 Mbits/sec 0.182 ms 5080/71364 (7.1%)
[ 4] 4.0- 6.0 sec 93.8 MBytes 393 Mbits/sec 0.482 ms 4650/71534 (6.5%)
[ 4] 4.00-6.00 sec 259 datagrams received out-of-order
[ 4] 6.0- 8.0 sec 94.8 MBytes 398 Mbits/sec 0.507 ms 3662/71305 (5.1%)
[ 4] 8.0-10.0 sec 93.9 MBytes 394 Mbits/sec 0.097 ms 4384/71393 (6.1%)
[ 4] 0.0-10.0 sec 465 MBytes 390 Mbits/sec 0.024 ms 2146796515/2147128384 (1e+02%)
[ 4] 0.00-10.01 sec 259 datagrams received out-of-order
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 56380
[ 3] 0.0- 2.0 sec 73.1 MBytes 307 Mbits/sec 0.020 ms 279/52442 (0.53%)
[ 3] 2.0- 4.0 sec 75.9 MBytes 318 Mbits/sec 0.033 ms 168/54315 (0.31%)
[ 3] 4.0- 6.0 sec 74.1 MBytes 311 Mbits/sec 0.035 ms 407/53293 (0.76%)
[ 3] 6.0- 8.0 sec 74.2 MBytes 311 Mbits/sec 0.026 ms 174/53137 (0.33%)
[ 3] 8.0-10.0 sec 75.4 MBytes 316 Mbits/sec 0.047 ms 37/53837 (0.069%)
[ 3] 8.00-10.00 sec 465 datagrams received out-of-order
[ 3] 0.0-10.0 sec 374 MBytes 313 Mbits/sec 0.031 ms 2146949725/2147216154 (1e+02%)
[ 3] 0.00-10.01 sec 465 datagrams received out-of-order
[ 4] local 10.0.0.9 port 580** connected with 94.16.123.* port 54993
[ 4] 0.0- 2.0 sec 49.1 MBytes 206 Mbits/sec 1.848 ms 98/35110 (0.28%)
[ 4] 0.00-2.00 sec 353 datagrams received out-of-order
[ 4] 2.0- 4.0 sec 49.9 MBytes 209 Mbits/sec 0.637 ms 32/35642 (0.09%)
[ 4] 2.00-4.00 sec 144 datagrams received out-of-order
[ 4] 4.0- 6.0 sec 49.9 MBytes 209 Mbits/sec 2.692 ms 2/35622 (0.0056%)
[ 4] 6.0- 8.0 sec 50.1 MBytes 210 Mbits/sec 0.114 ms 2/35711 (0.0056%)
[ 4] 8.0-10.0 sec 49.9 MBytes 209 Mbits/sec 0.080 ms 45/35665 (0.13%)
[ 4] 0.0-10.0 sec 249 MBytes 209 Mbits/sec 0.077 ms 2147128325/2147305897 (1e+02%)
[ 4] 0.00-10.01 sec 497 datagrams received out-of-order
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 50628
[ 3] 0.0- 2.0 sec 25.0 MBytes 105 Mbits/sec 0.146 ms 3/17851 (0.017%)
[ 3] 0.00-2.00 sec 205 datagrams received out-of-order
[ 3] 2.0- 4.0 sec 25.0 MBytes 105 Mbits/sec 0.087 ms 2/17839 (0.011%)
[ 3] 2.00-4.00 sec 190 datagrams received out-of-order
[ 3] 4.0- 6.0 sec 25.0 MBytes 105 Mbits/sec 0.090 ms 2/17833 (0.011%)
[ 3] 6.0- 8.0 sec 24.9 MBytes 105 Mbits/sec 0.125 ms 42/17830 (0.24%)
[ 3] 0.0-10.0 sec 125 MBytes 105 Mbits/sec 0.159 ms 2147305365/2147394482 (1e+02%)
[ 3] 0.00-10.00 sec 395 datagrams received out-of-order
maffle
Newbie
Beiträge: 55
Registriert: 01.01.2016, 01:53

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von maffle »

Hatte vor 2 Tagen Vodafone Twitter angeschrieben und mein Problem beschrieben. Kam nur kurz zurück dass sich die Fachabteilung sich das ansehn würde und melden würde, aber dass das länger dauern wird.

So nun wach ich heute auf und schau auf mein dauer test script was ich laufen habe auf meinem OpenWRT router zu dem Nvidia server

#!/bin/sh

while true
do
wget -O /dev/null http://us.download.nvidia.com/Windows/4 ... h-whql.exe
echo "done."
sleep 2
done

und starre etwas verblüfft auf den Wert... 64MB/s. Gestern war noch alles wie immer im Eimer, und das Problem mit dem Absinken nach 2 Sekunden war dauerhaft vorhanden. 64... 63.... 64.... 63.... wieder und immer wieder. Jedesmal max speed.

Dann schaue ich rüber zur VFS und siehe da... die LED Lampen sind an! Ich mach die immer aus, die VFS hat n bug, dass sich die LED Lampen immer einschalten nach einem reboot und er die Einstellung für LED off nicht speichert. Und siehe da.... es gab einen Reboot der Box vor gut 11 Stunden, also heute Nacht um 1:00 ca.

Firmware version angesehen... und ich hab ein Update bekommen... auf

AR01.02.037.03.14_081320_711.SIP.10

vorher war ich die letzten Monate auf:

AR01.02.037.03.12_112819_711.SIP.10

wget -O /dev/null http://us.download.nvidia.com/Windows/4 ... h-whql.exe läuft jetzt immer ohne Probleme mit max speed durch.

Am routing hat sich scheinbar nichts geändert:

Routenverfolgung zu cs5341561.wpc.phicdn.net [192.229.221.58]

über maximal 30 Hops:

1 <1 ms <1 ms <1 ms wrtarm.lan [10.0.0.199]
2 2 ms 2 ms 2 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
4 11 ms 11 ms 9 ms de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net [81.210.139.10]
5 14 ms 14 ms 17 ms de-fra01b-rc1-ae-7-0.aorta.net [84.116.197.50]
6 18 ms 16 ms 14 ms de-fra02a-ri1-ae-0-0.aorta.net [84.116.137.34]
7 16 ms 17 ms 15 ms 213.46.177.162
8 16 ms 29 ms 19 ms ae-65.core1.frc.edgecastcdn.net [152.195.100.129]
9 15 ms 14 ms 12 ms 192.229.221.58

Ablaufverfolgung beendet.

Dachte ich mir... oh mann. Lag es an der Firmware? Habe den nvidia download dann noch so 10 mal am Desktop getestet. Jedesmal max speed. Kein einziger Einbruch. Immer und immer wieder. Max speed. Gefixt!!!

Dann hab ich wget -O /dev/null http://v4.speedtest.belwue.net/1G getestet..... Einbruch. 7mb/s .... .....

dann wieder Nvidia getestet. Und jetzt ist der Nvidia Download auch wieder kaputt und verhält sich fehlerhaft.

WAS ZUM TEUFEL? Ich bin ratlos. Wie kann das bitte sein? Das einmalige ändern des downloads nach dem reboot/firmware update hat dazu geführt dass der andere Download jetzt auch wieder defekt ist. Dabei lief er immer und immer wieder max speed durch, bis ich kurz den wget -O /dev/null http://v4.speedtest.belwue.net/1G genommen hab dann zurück.

Wie ist sowas zu erklären? ........ ich bin ratlos.

Ich kann es mir nur so erklären, dass der andere Download irgendwie, wieso auch immer, die VFS dazu bewogen hat vielleicht einen anderen Docsis Kanal zu nehmen und dieser irgendwie fehlerhaft läuft, und ich dadurch "geflagt" bin am nächsten Hub, dass die Leitung gestört ist. Gibt es sowas? Und dass es nach dem Reboot der VFS "zufällig" auf Kanälen lief, wo es klappte... aber das ist doch total hanebüchen, ich kann mir nicht denken, dass es sowas gibt.
maffle
Newbie
Beiträge: 55
Registriert: 01.01.2016, 01:53

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von maffle »

Es hatte sich jetzt jemand im UM Forum gemeldet, bei dem genau das selbe Problem bzw Phänomen auftritt bei den gleichen Ziel-Servern die bei ihm auch über FRA1/FRA2 gehn, er wohnt ca 10KM von mir entfernt, und hat eine Fritzbox anstatt VFS, daran liegt es also nicht...
perler
Newbie
Beiträge: 4
Registriert: 21.01.2021, 20:37
Bundesland: Sachsen

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von perler »

um diesen netten thread nochmal aufzumachen. was noch nicht zur sprache kam (falls ich alles gelesen habe): die nicht-drossellung ist protokollabhängig, was für absicht spricht:

ssh (scp):

Code: Alles auswählen

scp root@domain.com:/vol/raid/data/test/test.bin .
test.bin                                                                                0%  428MB  20.5MB/s   57:31 ETA
https:

Code: Alles auswählen

wget https://domain.com/test.bin
--2021-01-21 20:19:16--  https://domain.com/test.bin
Resolving domain.com (domain.com)... 1.2.3.4, 1.2.3.5, 1.2.3.6, ...
Connecting to domain.com (domain.com)|1.2.3.7|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 74723385900 (70G) [application/octet-stream]
Saving to: ‘test.bin’

test.bin                        0%[                                                  ] 166.12M  7.49MB/s    eta 3h 8m  
gleiches file, gleicher server.

gegenprobe von (hier) digital ocean:

Code: Alles auswählen

wget https://domain.com/test.bin
--2021-01-21 19:43:18--  https://domain.com/test.bin
Resolving domain.com (domain.com)... 1.2.3.4
Connecting to domain.com (domain.com)|1.2.3.5|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 74723385900 (70G) [application/octet-stream]
Saving to: ‘test.bin’

test.bin                                         0%[     ... ] 311.23M  98.0MB/s    eta 12m 16s^
Flole
Insider
Beiträge: 9760
Registriert: 31.12.2015, 01:11

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von Flole »

perler hat geschrieben: 21.01.2021, 20:45 die nicht-drossellung ist protokollabhängig, was für absicht spricht
Das spricht eher für (bzw. gegen) einzelne Protokolle die natürlich alle unterschiedlich Arbeiten. "Absicht" kannst du nur dadurch zeigen das unterschiedliche Ports das beeinflussen. Da es alles verschlüsselt ist kann man da auch nicht Anhand des Protokolls irgendwas unterscheiden.
perler
Newbie
Beiträge: 4
Registriert: 21.01.2021, 20:37
Bundesland: Sachsen

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von perler »

dein satz ist ein bisschen unklar, aber ist doch eindeutig port 443 wir nicht gedrosselt und port 22 wird gar nicht gedrosselt.
Flole
Insider
Beiträge: 9760
Registriert: 31.12.2015, 01:11

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von Flole »

Nichts ist da eindeutig, du testest 2 völlig unterschiedliche Protokolle..... Das ist kein guter Test sondern Unsinn, denn allein durch die unterschiedlichen Protokolle sind unterschiedliche Ergebnisse zu erwarten. Bei einem guten (bzw. eigentlich schon bei einem sinnvollen) Test würde man dasselbe Ergebnis auf beiden Ports erwarten.
robert_s
Insider
Beiträge: 7262
Registriert: 30.11.2010, 15:09
Bundesland: Berlin

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von robert_s »

Flole hat geschrieben: 22.01.2021, 20:16 Nichts ist da eindeutig, du testest 2 völlig unterschiedliche Protokolle.....
Nicht nur das, auch unterschiedliche Clients und Server, mit unterschiedlichen Konfigurationen, Cipher Suites, etc. etc. Da kann der Unterschied an vielen Stellen liegen.

@perler: Für eine brauchbare Messung bitte den https-Server auf Port 22 konfigurieren, Messung durchführen, unmittelbar danach den SELBEN https-Server auf Port 443 umkonfigurieren und die GLEICHE Messung erneut durchführen. Das ganze 2-3x wiederholen um zu überprüfen, ob sich ein reproduzierbarer, signifikanter Unterschied zwischen beiden Ports zeigt.

Wenn dem so ist, ist aber auch noch nicht auszuschließen, dass der eigene Router sich unterschiedlich verhält (Stichworte NAT, Priorisierung). Ideal wäre eine Messung mit demselben Router an einem andersartigen, gleich schnellen, Anschluss, aber das könnte schwierig werden. Alternativ könnte man noch einen dritten, "zufälligen" Port > 1024 versuchen und sehen, was man aus dem Messergebnissen ableiten kann.
perler
Newbie
Beiträge: 4
Registriert: 21.01.2021, 20:37
Bundesland: Sachsen

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von perler »

@perler: Für eine brauchbare Messung bitte den https-Server auf Port 22 konfigurieren, Messung durchführen, unmittelbar danach den SELBEN https-Server auf Port 443 umkonfigurieren und die GLEICHE Messung erneut durchführen. Das ganze 2-3x wiederholen um zu überprüfen, ob sich ein reproduzierbarer, signifikanter Unterschied zwischen beiden Ports zeigt.
um euch die hards zu befriedigen :D

die bandbreitenprobleme sind so eindeutig, allein das hier ist beweis genug.

Code: Alles auswählen

$ wget https://speed.hetzner.de/10GB.bin
--2021-01-23 16:27:57--  https://speed.hetzner.de/10GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 213.133.106.251, 193.47.99.4, ...
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/octet-stream]
Saving to: ‘10GB.bin.1’

10GB.bin.1                      1%[                                                  ] 120.83M  6.87MB/s    eta 24m 27s^C
$ wget -O /dev/null http://speedtest.tele2.net/1GB.zip
--2021-01-23 16:28:18--  http://speedtest.tele2.net/1GB.zip
Resolving speedtest.tele2.net (speedtest.tele2.net)... 90.130.70.73, 2a00:800:1010::1
Connecting to speedtest.tele2.net (speedtest.tele2.net)|90.130.70.73|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/zip]
Saving to: ‘/dev/null’

/dev/null                      24%[===========>                                      ] 250.18M  34.5MB/s    eta 23s    ^
nix "NAT priorisierung" oder was immer ihr braucht um euer Ego im Griff zu behalten. Wenn etwas aussieht wie eine Ente und quakt wie eine Ente ist es mit großer Wahrscheinlichkeit eine Drossel.
robert_s
Insider
Beiträge: 7262
Registriert: 30.11.2010, 15:09
Bundesland: Berlin

Re: Drosselung bei Vodafone West (Aorta-Backbone)?

Beitrag von robert_s »

perler hat geschrieben: 23.01.2021, 16:35 Wenn etwas aussieht wie eine Ente und quakt wie eine Ente ist es mit großer Wahrscheinlichkeit eine Drossel.
Nein, dann ist es eine Ente, wie in diesem Fall. Was Du da zeigst, beweist eigentlich nur, dass Du offenbar weder weißt, wie das Internet funktioniert, noch, wie man Thesen verifiziert. Dass Dir das alles zu akademisch sein mag, ist ja ok. Aber dann nimm doch bitte davon Abstand, Deine bloßen "Ahnungen" als Fakten darzustellen. Du bist nicht Willens oder in der Lage, Deine Annahmen zu verifizieren, oder auf Leute zu hören, die wissen, wie man so etwas anstellt.