Snelheidsproblemen door te weinig capaciteit.

jtech zei:

En hoe gaat het downloaden via http? Een speedtest zegt gewoon niet zoveel helaas.

Klik om te vergroten...

https://speedtest.onsbrabantnet.nl/files/1024MByte.bin komt ook ongeveer met 560kb/s binnen.
https://www.pro-noc.nl/1000mb.bin met 4.0MB/s
ftp://dl.solcon.nl/pub/test/1000mb.bin met 5.0MB/s
ftp://ftp.xs4all.nl/pub/test/100mb.bin met 2.0MB/s
https://85.17.128.2/100mb.bin met 670kb/s
https://www.kpnbroadbandvalley.nl/mxarena/downloads/100mb.bin met 280kb/s
https://www.streamservice.nl/1000mb.bin met 7.0MB/s

Snelheden heel erg verschillend dus.
Mijn SFTP sessies komen vanaf OVH en XMSnet (glasvezel)

Ik denk dat we met de huidige snelheden die UPC biedt ook steeds meer te maken krijgen met knelpunten elders op internet. Uit jouw opsomming is dat ook wel enigszins op te maken.

jtech zei:

Ik denk dat we met de huidige snelheden die UPC biedt ook steeds meer te maken krijgen met knelpunten elders op internet. Uit jouw opsomming is dat ook wel enigszins op te maken.

Klik om te vergroten...

Mhah, als ik vanaf server 1 naar mijn eigen pc download haal ik 500-600kb/s
als ik vanaf server 1 naar een XMSnet pc download haal ik 5MB/s (aangesloten op 50Mbit)
als ik vanaf dezelfde XMSnet pc download naar mijn pc haal ik 500-600kb/s


rara, waar zit het dan.

Geen idee waar het in dit specifieke geval precies zit, maar internetverkeer gaat natuurlijk over een aantal schakels. Er hoeft in de ketting maar 1 zwakke schakel te zitten en je hebt al een probleem. Het ligt misschien voor de hand om in jouw voorbeeld de bal bij UPC neer te leggen, maar dan moet je wel het hele routeringsverhaal kennen.

jtech zei:

Geen idee waar het in dit specifieke geval precies zit, maar internetverkeer gaat natuurlijk over een aantal schakels. Er hoeft in de ketting maar 1 zwakke schakel te zitten en je hebt al een probleem. Het ligt misschien voor de hand om in jouw voorbeeld de bal bij UPC neer te leggen, maar dan moet je wel het hele routeringsverhaal kennen.

Klik om te vergroten...

Ziehier :

OVH->UPC
traceroute to UPC (xxxxxx), 30 hops max, 60 byte packets
1 rbx-20-m2.fr.eu (91.121.75.252) 0.568 ms 1.155 ms 1.498 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.247 ms * *
3 * * *
4 gblx.as3549.fr.eu (213.186.32.129) 4.130 ms 4.163 ms 4.202 ms
5 upc-1.ar6.lon3.gblx.net (64.212.107.14) 23.182 ms * 23.188 ms
6 84.116.132.61 (84.116.132.61) 21.165 ms 32.861 ms 21.518 ms
7 nl-ams02a-rd1-tg-0-6-0-5.aorta.net (84.116.130.33) 26.255 ms 26.250 ms 26.247 ms
8 84.116.244.34 (84.116.244.34) 22.371 ms 22.135 ms 22.227 ms
9 p6014.net.upc.nl (212.142.6.14) 19.817 ms 19.828 ms 19.821 ms
10 UPC (xxxxxxxx) 47.245 ms !X 41.310 ms !X 27.403 ms !X

OVH->XMSnet
traceroute to XMSnet (xxxxxx2), 30 hops max, 60 byte packets
1 rbx-20-m2.fr.eu (91.121.75.252) 1.466 ms 1.664 ms 1.924 ms
2 rbx-1-6k.fr.eu (213.251.191.1) 0.542 ms * *
3 ams-5-6k.nl.eu (213.251.130.66) 5.807 ms * *
4 pr1.nik-asd.internl.net (195.69.144.204) 5.978 ms 6.027 ms 6.032 ms
5 217.149.196.102 (217.149.196.102) 6.222 ms 6.115 ms 6.225 ms
6 XMSnet (xxxxxx2) 8.995 ms 9.590 ms 9.038 ms

Dat zijn een 4 tal hops minder, plus het gaat van OVH->XMSnet een stuk sneller

XMSnet->UPC
traceroute to UPC (xxxxxxxx), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.259 ms 0.271 ms 0.337 ms
2 1-121-92.ftth.xms.internl.net (92.254.121.1) 10.114 ms 10.612 ms 10.751 ms
3 vlan335.newxr1.nik-asd.internl.net (217.149.196.45) 10.971 ms 10.808 ms 10.972 ms
4 ams13-core-1.tengigabiteth2-1.swip.net (130.244.200.137) 11.147 ms 11.322 ms 11.496 ms
5 nl-ams04a-ri2-ge-7-0-0.aorta.net (213.46.183.53) 11.671 ms 11.843 ms 12.012 ms
6 84-116-130-177.aorta.net (84.116.130.177) 12.843 ms 84.116.132.217 (84.116.132.217) 4.082 ms 5.087 ms
7 84.116.244.34 (84.116.244.34) 20.399 ms 11.904 ms 12.070 ms
8 p6014.net.upc.nl (212.142.6.14) 12.550 ms 13.128 ms 13.865 ms
9 UPC (xxxxxxxxx) 26.616 ms !X 26.790 ms !X 31.862 ms !X

Ja oké, maar je kan wellicht ook tig andere voorbeelden verzinnen waarbij het wel goed gaat. Je punt is duidelijk, maar ik weet niet hoe ik het allemaal moet duiden als je naar het grotere geheel kijkt. Zou zomaar kunnen dat je volledig gelijk hebt, maar de bewijsvoering is natuurlijk nogal dun.

Als ik download van al de linken die postduif noemde, varieert mijn download ook van 500 kB/s tot 4 MB/s, terwijl de speedtesten van speedtest.net wel 60 Mb/s (7,5 MB/s) aangeven.

loosoft zei:

Als ik download van al de linken die postduif noemde, varieert mijn download ook van 500 kB/s tot 4 MB/s, terwijl de speedtesten van speedtest.net wel 60 Mb/s (7,5 MB/s) aangeven.

Klik om te vergroten...

Ja, en dat bewijst nog steeds alleen maar dat dit geldt voor de genoemde servers. Bij een andere set van servers kan je dus zomaar een heel andere uitkomst krijgen. Kortom: het is nogal moeilijk om op basis van een zeer beperkt aantal tests verregaande conclusies te trekken.

Klopt volkomen wat je zegt, jtech, maar ik gebruik toevallig al langer twee van de genoemde servers (onsbrabantnet en xs4all) om de download te testen en die geven vrij constant een download van 7,5 MB/s.

jtech zei:

Ja, en dat bewijst nog steeds alleen maar dat dit geldt voor de genoemde servers. Bij een andere set van servers kan je dus zomaar een heel andere uitkomst krijgen. Kortom: het is nogal moeilijk om op basis van een zeer beperkt aantal tests verregaande conclusies te trekken.

Klik om te vergroten...

De conclusie die ik doe is dat :

1. UPC 's avonds rond 17.00 tot 22.00u QOS nodig heeft op http verkeer, en hierbij verkeer over poort 22 afknijpt.
of
2. UPC 's avonds rond 17.00 tot 22.00 peering problemen heeft.

Ik zou het kunnen uittesten door hetzelfde scp verkeer over poort 80 te sturen, dan kan ik uitsluiten of er DPI plaatsvind of niet.

Met mijn eigen connectie is er niks aan de hand, dat heb ik ook nooit beweerd. Het ligt puur aan het netwerk van UPC zelf. Probleem is alleen dat ik juist rond dit tijdstip m'n data nodig heb.