pimzand

Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes

Upload snelheid: speedtest versus werkelijkheid

Kent iemand dit fenomeen:

Je internetverbinding werkt prima, speedtest geeft aan dat je de 400/40 mbit/s snelheid echt haalt,
en je ziet dit ook terug in upload en download snelheden met applicaties die 1 enkele TCP connectie
bouwen, zoals wget of rsync.

Dan, merk je ineens heb je maar een derde van de uploadsnelheid hebt.
ca 12-13 mbit gemiddeld, met een grillig verloop (fnuikend voor streaming).
Maar Ziggo/Ookla speedtest zegt dat er niets aan de hand is.
Als ik nload mee laat lopen tijdens de speedtest zie ik ook echt die snelheid.
Als ik Wireshark mee laat lopen zie ik geen packet loss of retransmissions.

Maar als ik vanaf een ander netwerk iets download van mijn servertje
met wget of rsync zie ik die grillige verlopende trage uploads.
Dat andere netwerk is dan _elk_ netwerk wat ik probeer:
- TransIP datacenter, 1000/1000 mbps
- Vodafone Enterprise glasvezel, 200/200 mbps
- Ziggo Zakelijk, zelfde regio, 40/4 mbps
- Ziggo Consumer, zelfde regio, 40/4 mbps
Het verkeer tussen al deze andere netwerken onderling is optimaal.

Deze traagheid kan weken aanhouden, maar kan van het ene moment op het andere
weer voorbij zijn. En na een week of wat weer terugkomen... De laatste tijd is het
echter vaker traag dan snel. Maar vanwege de goede speedtest resultaten hoef ik
niet naar de helpdesk te stappen.

Nu weet ik dat de speedtest meerdere TCP connecties bouwt, en ik weet dat dat helpt
op verbindingen met een relatief hoge latency, maar dat verklaart niet waarom het zo lang
wel goed gewerkt heeft met wget en rsync, en af en toe nog steeds goed werkt.

Herkent iemand dit? Heeft iemand een verklaring?

Achtergrondinformatie:
Ik heb een Connect Box 400/40 in bridge modus.
Ik gebruik een Linux server met plenty power, met Intel gigabit NICs als router.
De Linux server zelf gebruikt dus geen NAT voor uploads.
Ik gebruik ook een IPv6 tunnel naar een third party, maar alle metingen zijn over native IPv4.
In 2016 had ik ook een trage upload, maar dat was ook te zien in speedtest.
Na een lang proces van modemwissels en monteurbezoeken is dit uiteindelijk opgelost
nadat een andere monteur iets gedaan heeft in het kastje op straat.
Oplossing

Geaccepteerde oplossingen
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Op het kaartje heeft Remco geschreven:

Ruis uit het netwerk gehaald (wijkcentrale)
Speedtest in versterker buiten gaat prima

Bekijk in context

92 Reacties 92
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Ik heb nog een Technicolor TC7210 liggen, ongebruikt, ooit van Ziggo ontvangen
na een storingmelding. Ik wilde die eens proberen, maar het modem moet
worden geactiveerd. Kan dat nog, nu ik later een Connect Box heb ontvangen?
Verwijderd account
Niet van toepassing
pimzand wrote:
Ik heb nog een Technicolor TC7210 liggen, ongebruikt, ooit van Ziggo ontvangen
na een storingmelding. Ik wilde die eens proberen, maar het modem moet
worden geactiveerd. Kan dat nog, nu ik later een Connect Box heb ontvangen?

Het oude modem kan niet meer geactiveerd worden nadat je nieuwe modem in werking is gesteld.
Bewaar je oude modem wel goed, want je zult een verzoek ontvangen of reeds ontvangen hebben om het oude modem retour te sturen naar Ziggo.
Bert

Level 21
T.E.A.M.
  • 75187Posts
  • 5145Oplossingen
  • 21925Likes
Kun je hier je downstream en upstream waarden uit je modem plaatsen met een screenshot?
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Zeker:


pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Nog meer info:

De Connect Box is een Compal, hardware versie 4.01, firmware CH7465LG-NCIP-4.50.18.23-4m1-GA-NOSH
Bert

Level 21
T.E.A.M.
  • 75187Posts
  • 5145Oplossingen
  • 21925Likes
Je signaalkwaliteit kunnen we uitsluiten, die is uitstekend.

Hier lijkt evem meekijken door een Ziggo moderator een idee, zij kunnen nog meer zien.
Zij komen eens in de paar werkdagen langs in ieder topic.
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Zijn de waardes ook niet te hoog? Er zit een Tratec versterker tussen AOP en modem, en een langer dan aanbevolen kabel.

Maar ik heb al eens eerder het modem rechtstreeks op de AOP aangesloten, met een laptop getest, en zag de exact zelfde snelheden.
Bert

Level 21
T.E.A.M.
  • 75187Posts
  • 5145Oplossingen
  • 21925Likes
Je downstream gaat pas een issue worden bij standaard: +11 en dit modem kan nog meer hebben.

Maar een langere kabel en een versterker kunnen wel extra storingen veroorzaken.

AOP > splitter 1e uitgang > modem
splitter 2e uitgang > versterker.

Hoe minder ertussen, hoe minder kans op storing.
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Ik zie dat ik wel met 40 mbps kan uploaden over UDP met minimale packet loss.
Ik meet dat met nuttcp (http://nuttcp.net/nuttcp/nuttcp.html)


nuttcp -u -i -Ri40m remote.nuttcp.server
4.7373 MB / 1.00 sec = 39.7371 Mbps 34 / 4885 ~drop/pkt 0.70 ~%loss
4.6855 MB / 1.00 sec = 39.3055 Mbps 43 / 4841 ~drop/pkt 0.89 ~%loss
4.7549 MB / 1.00 sec = 39.8843 Mbps 40 / 4909 ~drop/pkt 0.81 ~%loss
4.7773 MB / 1.00 sec = 40.0777 Mbps 32 / 4924 ~drop/pkt 0.65 ~%loss
4.7539 MB / 1.00 sec = 39.8786 Mbps 29 / 4897 ~drop/pkt 0.59 ~%loss
4.7363 MB / 1.00 sec = 39.7312 Mbps 29 / 4879 ~drop/pkt 0.59 ~%loss
4.7051 MB / 1.00 sec = 39.4691 Mbps 43 / 4861 ~drop/pkt 0.88 ~%loss
4.6904 MB / 1.00 sec = 39.3463 Mbps 67 / 4870 ~drop/pkt 1.38 ~%loss
4.7852 MB / 1.00 sec = 40.1391 Mbps 23 / 4923 ~drop/pkt 0.47 ~%loss

47.3086 MB / 9.99 sec = 39.7159 Mbps 99 %TX 2 %RX 384 / 48828 drop/pkt 0.79 %loss


Zie dan hoe langzaam en grillig TCP uploads zijn:


nuttcp -i remote.nuttcp.server
1.0000 MB / 1.00 sec = 8.3874 Mbps 0 retrans
1.5625 MB / 1.00 sec = 13.1072 Mbps 0 retrans
0.8125 MB / 1.00 sec = 6.8162 Mbps 0 retrans
1.0625 MB / 1.00 sec = 8.9124 Mbps 0 retrans
1.0625 MB / 1.00 sec = 8.9128 Mbps 0 retrans
1.5625 MB / 1.00 sec = 13.1079 Mbps 0 retrans
1.5000 MB / 1.00 sec = 12.5832 Mbps 0 retrans
1.6875 MB / 1.00 sec = 14.1554 Mbps 0 retrans
0.9375 MB / 1.00 sec = 7.8647 Mbps 0 retrans
1.3125 MB / 1.00 sec = 11.0100 Mbps 0 retrans

12.7500 MB / 10.12 sec = 10.5675 Mbps 0 %TX 1 %RX 0 retrans 13.38 msRTT
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
nuttcp is een handige tool, ik kan er ook mee via multiple streams uploaden.
Met 10 connecties kom ik een beetje in de buurt van wat ik anders gewoon met 1 ook haalde:


nuttcp -i -N10 remote.nuttcp.server
3.6875 MB / 1.00 sec = 30.9284 Mbps
3.9375 MB / 1.00 sec = 33.0314 Mbps
3.6875 MB / 1.00 sec = 30.9302 Mbps
4.2500 MB / 1.00 sec = 35.6545 Mbps
4.5000 MB / 1.00 sec = 37.7479 Mbps
4.6250 MB / 1.00 sec = 38.7970 Mbps
4.3750 MB / 1.00 sec = 36.7015 Mbps
4.5000 MB / 1.00 sec = 37.7505 Mbps
4.6250 MB / 1.00 sec = 38.7979 Mbps
4.5000 MB / 1.00 sec = 37.7485 Mbps

44.0496 MB / 10.28 sec = 35.9563 Mbps 0 %TX 0 %RX 21.60 msRTT
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Ik lees nu voor het eerst over de Puma 6 problematiek.
Is dit een manifestatie van dit probleem?
Of is het een bijwerking van pogingen om dit probleem te verhelpen in firmware updates?

Ik zou het wel heel zuur vinden als het Technicolor TC7210 modem dat ik in huis heb de oplossing zou zijn,
maar Ziggo het zou weigeren te activeren.

Ik heb ook nog een Ubee modem zonder wifi.
Ik zou er zo naar teruggaan als ik daar de maximale uploadsnelheid terugkrijg.
Bert

Level 21
T.E.A.M.
  • 75187Posts
  • 5145Oplossingen
  • 21925Likes
De komende werkdagen komen hier ook Ziggo moderators voorbij, die kunnen ook eens meekijken met je.
Misschien kunnen zij de andere modems een keer activeren en kijken of er een beter resultaat te behalen is.
Michael Z1
Oud Community Moderator
Oud Community Moderator
  • 2609Posts
  • 346Oplossingen
  • 522Likes
Top dat je aan de bel trekt, pimzand. Ik denk graag met je mee! Wil je mij in een persoonlijk bericht je adresgegevens sturen? Je stuurt mij een bericht door op m'n naam te klikken en dan voor 'Stuur bericht' te kiezen.
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Bedankt Michael. Ondertussen kan ik aan de community melden dat het nu weer top is. Ik krijg nu weer 39 mbit/s over een enkele TCP connectie, wat ongeveer het theoretische maximum is voor TCP voor deze connectie.
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Ik kan hier ook nog aan toevoegen dat er niets is veranderd aan mijn of aan remote zijde(n).
Aan mijn zijde is de modem nooit herstart, en is er dus nog dezelfde firmware.
Mijn Linux server is ook niet geherstart geweest.

Mijn idee is dat dit alles niets met mijn modem te maken heeft, maar eerder met Ziggo infrastructuur.
Waarschijnlijk zal Michael daar meer over kunnen zeggen.
Michael Z1
Oud Community Moderator
Oud Community Moderator
  • 2609Posts
  • 346Oplossingen
  • 522Likes
pimzand wrote:
Bedankt Michael. Ondertussen kan ik aan de community melden dat het nu weer top is. Ik krijg nu weer 39 mbit/s over een enkele TCP connectie, wat ongeveer het theoretische maximum is voor TCP voor deze connectie.

Goed om te lezen! Ik durf niet te zeggen waar dit aan heeft gelegen. Mocht het probleem weer terugkomen, laat het me dan weten!
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Zo plotseling als het probleem verdween, zo plotseling is het weer terug.
Ik zie nu 6,5 mbit/s over 1 TCP connectie, versus 39 mbit/s voorheen.
10 parallelle connecties levert 29,9 mbps op.
Ik meet dit alles op afstand via nuttcp.

Als ik weer thuis ben zal ik een speedtest draaien.
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Ik ben weer thuis. Ookla speedtest zegt 409.46 down, 39.45 up.
Dus de rauwe bandbreedte is er.

TCP performance is inmiddels iets minder slecht, 14 mbps up over 1 TCP connectie,
37 mbps over 10 connecties. Maar nog steeds maar 1/3 van de real-world
snelheid die ik een week lang heb mogen genieten.

Ik heb vorige week, toen alles even goed was enkele traceroutes gerund.
Het zou kunnen dat de slechte TCP performance voortkomt uit ongunstige routes.
Dat is niet het geval. Alle routes zijn 100% identiek. De ping tijden zijn zelfs nu iets beter.
pimzand
Topicstarter
Level 7
  • 139Posts
  • 2Oplossingen
  • 40Likes
Is deze error log melding gerelateerd?

08-02-2018 11:42:03 critical No Ranging Response received - T3 time-out;CM-MAC=90:5c:44:3c:a5:e8;CMTS-MAC=00:01:5c:70:da:49;CM-QOS=1.1;CM-VER=3.0;

Uitgelicht topic