Gisteren naar de klantendienst gebeld,volgend gesprek vond plaats tussen mezelf(M) en telenet(T)
T:Goedemiddag met....
M:Goedemiddag,ik ben overgeschakeld van mono naar expresnet en mijn snelheid is nu nog lager dan voordien.
T:Een ogenblikje ik test uw verbinding,wil u eens speetest.telenet.nl ingeven?>>>alles is normaal!>>>u hebt toch geen spyware?
M:Mevrouw ik lees op diverse forums welke de snelheden zouden moeten zijn en die haal ik dus niet.
T:Ik lees die dus niet.
M:U zou dat beter wel doen,ipv een standaard briefje af te lezen en de klanten steeds maar afscheppen met steeds over spyware etc.te beginen.
Ik kan u verzekeren dat de pc 100% vrij is van wat dan ook.
T: (nog steeds even vriendelijk)Mijnheer ik kan u enkel maar zeggen dat de cijfers die u behaald volkomen normaal zijn.
M:U bent dus niet van zin om er iets aan te doen
T:Wat wil u dat er aan gedaan word?
M:U zou een andere modem kunnen komen plaatsen ik wer noch steeds met een oude cybersurf en daarvan is reeds bewezen dat die de snelheden van expresnet niet aankan.
T: Dat zou ik kunnen vragen,momentje ik vraag het even maar kan niet sbeloven want alles is in orde bij u.>>>>>>mijnheer wij kunnen uw modem morgen komen omruilen.
M:in orde bedankt!
Vanmorgen om 8uur stond die technieker hier al,resultaat is verbluffend nu!
zie hier (http://users.pandora.be/userman/downloadvenster%2012%20-7.jpg)
De technieker is ook zo vriendelijk geweest om mij een adres te geven van een telenettechnieker die op zijn wepspace zelf een aantal tests heeft staan om de downlodsnelheid te testen.
http://users.telenet.be/downloadtest/ (http://users.telenet.be/downloadtest/)

Zo zie je maar dat de volhouder wint :)
Als er iets is wat ambetant is, dan is het wel downloaden aan lage snelheid terwijl je voor een hoge snelheid betaald.
Ben blij voor je dat dit opgelost is.

Had ik in het begin ook...
Toen heeft Pandora's UserBase kunnen aantonen dat de niet gehaalde snelheden lagen aan de oude CyberSurf en ik ben dan vlug lid geworden van PUB.

Enkele dagen later mijn modem geplaatst :)

De enige test die wij als technieker kunnen uitvoeren om de correcte snelheden te meten zijn eigenlijk niet voor de modale surfer bedoeld. Ook deze test gaat je niet de correcte snelheid doorgeven. Wanneer wij een test uitvoeren, mogen er max 10 techniekers op hetzelfde ogenblik deze test doen en dan is deze test ook nog regio-afhankelijk. De meest install techniekers kennen deze snelheidstest zelfs niet dus de snelheid zal in de buurt zitten maar nog steeds niet correct.

WIj hebben zo ook eens wat problemen gehad, en toen ging die gast vanalles meten,
en hebben we ook ne nieuwe modem gekregen :p

Dat is ook onze opdracht he Eventure. Mensen verwachten een bepaalde snelheid en wanneer men daar dan niet aan komt is men niet tevreden. Vaak hangt het af van vele factoren. Van de connector in de tap tot alle kabels moeten perfect verzorgd zijn. Vaak zijn de kabels in de woningen van erbarmelijke kwaliteit. Investeren hierin kan nooit geen kwaad. Enkel dan kan men er vanuit gaan dat we de exacte snelheid kunnen meten.

Mijn telefoonmodem was kapot gegaan. Zaterdagmorgen gebeld (met gsm). Maandagmorgen alles vervangen. Vroeger 5 bakjes, nu maar 1 meer. Zo hoort dat.

De enige test die wij als technieker kunnen uitvoeren om de correcte snelheden te meten zijn eigenlijk niet voor de modale surfer bedoeld. Ook deze test gaat je niet de correcte snelheid doorgeven. Wanneer wij een test uitvoeren, mogen er max 10 techniekers op hetzelfde ogenblik deze test doen en dan is deze test ook nog regio-afhankelijk. De meest install techniekers kennen deze snelheidstest zelfs niet dus de snelheid zal in de buurt zitten maar nog steeds niet correct.

Hierin kan ik je totaal bijtreden....

een trough-put test bestaat uit verschillende onderdelen.

1. frames met een MTU (max tansmission unit) van 64KB doorsturen, voor x-aantal tijd, op basis van het resultaat kan je dan de [framsize(64 in dit geval)]+[4bytes crc] X [aantal doorgestuurde frames] X 8(om tot bits te komen) / 1024 (kilobits) /1024 (megabit) ---> dit geeft je een beeld over de troughput van de lijn in megabit (Mb/s)

2. frames met een MTU van 1518KB (1492KB voor xdsl) zelfde test. het resultaat is dat je bij grotere frames minder overhead hebt en dus meer data door uw lijn krijgt. nadeel voor real-time oplossingen zoals bijvoorbeeld VOIP ( voice over ip ) hiervoor moet je mtu kleiner staan zodat de frames sneller vol zitten en op de draad kunnen gezet worden.

2. round trip delay. dit is de tijd dat het frame nodig heeft om van punt A naar punt B en terug naar punt A te geraken, dit wordt eveneens getest met grote en kleine frames.

TCP is eigenlijk geen 'valid' protocol om dit soort tests uit te voeren , daar het werkt met een 3-way handshake dus moet er telkens een ack packet terugkomen alvorens het volgende packet kan verzonden worden. UDP is een beter protocol om dit soort testen uit tevoeren...

last but not least, dit soort testen gebruikt veel resourses, dus is het aangewezen geen andere proccessen uit te voeren op de machines waar de test in progress is, dit heeft een negatief effect op uw testresultaten en geeft dus een vertekend beeld....


groeten
L.