OK, Maar wat de stellen de cijfers dan voor wanneer de ontsluiting naar de ISP zelf “slechter” zijn dan voorbij die ISP ? de speedtest fluctueert (150-350Mbps) en is substantieel slechter dan een binaire uitwisseling die wmb constante (++980Mbps) resultaten geven.
Excuses voor de vast te simpele vraagstelling. Ik snap niet wat de cijfers inhoudelijk voorstellen.
Dat ik “ze” kan gebruiken als uitgangspunt voor een eigen/interne vergelijking om bv aan te tonen dat wifi’s abc slechter doet dan vast en/of browser gedoe interfereert, is helder.
In dat verband worden de cijfers onvergelijkbaar met andere gebruikers omdat iederteen een net wat andere configuratie of (wifi) opstelling zal hebben. Wat verder dan de exacte meerwaarde is voor een ISP anders dan speedtest een soort van referentie/klok te bieden, ontgaat mij vervolgens.
Tijd dat @Freedom iets gaat uitleggen wat ik/we aan het meten zijn.
De rare verschillen tussen download- en upload snelheden hebben onze volle aandacht. Het is een heel lastig probleem omdat we niet zelf de problemen kunnen reproduceren. Maar dat er problemen reëel zijn is ons meer dan duidelijk.
Na inventariseren van de klachten lijken deze zich te beperken tot gigabit aansluitingen op het KPN access-netwerk. We hebben een aantal kandidaat-oorzaken bedacht en zijn die voor zover als we kunnen aan het uitsluiten. Het onderhoud van vannacht is een netwerk-element uitgesloten en we gaan kijken of dit effect heeft. Zo niet dan gaan we verder met het verprutsen van onze nachtrust.
Ook hebben we inmiddels zelf twee privacy-vriendelijke speedtestservers. Door te testen met deze servers kunnen we upstream en peering buiten beschouwing laten. We hebben de servers inmiddels op twee verschillende plekken in het netwerk zitten waardoor we ook weer een aantal elementen kunnen uitsluiten mochten er duidelijke verschillen te zien zijn in resultaten tussen de twee servers.
Die speedtestservers behoeven nog meer werk. Zo hoop ik dat we in de loop van de dag ook HTTP (naast HTTPS) kunnen doen om TLS-overhead weg te werken. Ook zullen we op servers sparse files ter download met curl of wget gaan aanbieden. Ook moeten de servers nog verschillende hostnames voor IPv4, en IPv6 in DNS te krijgen.
Desalniettemin is het al nuttig om speedtests te doen met onze servers. Daarbij zou een packet-trace (packet capture) helemaal handig zijn. We maken deze ook op de speedtest servers van het http(s) verkeer. Mogelijk leveren vergelijkingen tussen de twee kanten van de verbindingen inzage in eventuele oorzaken in de access-netwerken die niet onder ons beheer zijn.
Nog maar eens een test. Twee keer omdat de eerste niet optimaal was. Dit is op mijn router met iPerf3. Aan de andere kant een dedicated server bij NFOrce (1x gigabit).
Bekend. Daar staat niks anders dan dat er wat is, noch legt het uit wat het meet… en wij maar babbelen over cijfers met wat dat kan zijn. Zelf heb en zie ik geen probleem, mijn doorvoer ziet er prima uit en anders dan dat de speedtest cijfers mij doen zouden geloven.
Nogmaals, meten aan wat er allemaal tussenzit van gebruikers; lijkt mij weinig zinvol. Je zult eerst een baseline moeten doen op de connectie zelf voordat je daaraan kunt gaan refereren.
Het probleem van veel klagers zit tussen fritzbox en ELDERS… alleen is elders steeds iets waar freedom geen meet waarden van kan krijgen. Dus nu kan er ook een speed test bij freedom zelf worden aangemaakt.
Dan zit er tussen Fritzbox en Freedom speed test host niets anders dan bekende componenten (routers & servers van Freedom, Fritzbox en connection provider…) Dus als je de performance van connection providers wil meten (zie eerder melding van Arien) heb je met een server bij freedom en een meetapparaat bij de mensen thuis (PC die speed test runt en evt. ook een wireshark capture maakt) een aardig beeld waar het misgaat als het mis is.
Mijn staatjes zien er heel goed uit… Ik heb verder dan ook geen reden van klagen.
Wat we tot dusver denken te hebben gezien is het volgende.
Bij downloads naar klanten met KPN-verbindingen blijft de TCP-window size als het ware ‘klein’. Dat maakt de doorvoersnelheid ‘steady’ maar relatief laag. Dat is zo met onze eigen speedtest servers, maar niet voor sommige servers van anderen. Daar zien we de window groter worden en daarmee de doorvoersnelheid ook.
Doen we de testen via verbindingen in ons eigen netwerk of via upstream en peering dan zien we dit gedrag niet in die mate. Daarmee kunnen we tot meerdere gigabits per seconde down- en upload snelheden meten.
De doorvoersnelheid, de maximale bit-rate, van de betreffende KPN-verbindingen zijn vaak prima. Zet je meerdere TCP-streams naast elkaar op dan is de totale doorvoer vrijwel altijd goed. Sommige klanten hadden dit al gezien, Bovendien bevestigen enkele testen via UDP met Fritz!boxen als iPerf server deze conclusie ook.
Het is mogelijk om sparse files te downloaden van de speedtest-servers, maar we zien geen verschil met de webinterface. We hebben nog geen paginaatje gemaakt met links voor deze files. De resultaten uit de web-interface komen min-of-meer overeen met wat we uit de packet-captures halen.
We zien ook geen wezenlijke verschillen tussen IPv4 en IPv6. De netwerkpaden van- en naar speedtest-servers van anderen geven ook geen uitsluitsel. We hebben inmiddels ook hele delen van ons eigen netwerk uitgesloten als oorzaak.
We hebben het gedrag weten te reproduceren van een KPN-WBA aansluiting van een Freedom medewerker. Daar gaan we verder mee testen.
Packet captures zijn nog steeds welkom hoor. We hebben lang niet alle data die is aangeleverd al bekeken. Maar eh… we worden ook een beetje gaar. Een beetje afstand nemen kan ook geen kwaad.
Goed verhaal, strookt met mijn overwegingen van (relatief) ongrijpbare aard en verklaart de (sterk wisselende) doorvoer. Doet mij denken dat het hebben van een 1Gbit aansluiting totaal niets zegt met wat je daarmee (niet) kunt doen.
Totale doorvoer kan prima zijn omdat (internetwerk) grotere windowssizes gebruikt worden en stort dan ineen bij wanneer die kleiner worden (en er dus meer ack’s cq of her/transmissies nodig zijn).
Met (default = actieve) windowsscaling krijg ik mijn maximale doorvoer met een afwijkende speedtest.
Als ik ping naar speedtest.freedom gewoon op de dos prompt.
Zwabbert de ping ook tussen 3 en 6 ms
Via browser in Ookla bereik ik 4ms naar systemen rond Amsterdam
speedtest.freedom geeft afhankelijk van de browser 8 tot 13ms ( Iron en FF)
Tenzij je een data lurker bent, kan dat wellicht nog wel flink lager. Het hele snelheidsgedoe, als het gaat om geld, is imo vooral marketing waar dan een paar echte grootverbruikers mee aan hun trekken kunnen komen. Ik ken iemand die - unfair - zijn halve flat laat meeliften voor €5/maand.
Ik had (xs4all) de laatste jaren 50Mbit waar we prima mee uitkwamen. We verstoken in een paar plukjes over de dag, iets van 50-100GB/maand. Met een 5Mbit zou ik ook al prima uitgekomen zijn. Toegegeven dat we eigenlijk alleen maar mailen/browsen met af en toe een sync/download.
Belangrijk van mijn sneldheid is dat het in korte tijd kan (bursten). Voor het overgrote deel van de tijd, is het kunnen hebben van snelheid/vermogen (denk aan je auto) dat een beetje tussen de oren zit en dan door marketeers wordt uitgenut om je disproportioneel voor te laten betalen. Mijn cat5/switch/routers worden/zijn niet goedkoper of duurder.
Eens meestal is de capaciteit niet nodig, maar is de burst af en toe wel handig.
Voor mij is belangrijk dat de snelheden symmetrisch zijn, (asymmetrisch veroorzaakt alleen maar vertragingen), en een upload snelheid van ~100Mbps. (voor redelijke tunnels…)…
Niet heel veel. We hebben ook veel tijd en energie gestoken in het oplossen van wat uiteindelijk lokale netwerk issues bleken te zijn. Of het ging om lijnen met slechte belichting.
Als al die zaken zijn uitgesloten, dan zien de download snelheid toch beneden de gigabit blijft. We weten niet weten waar die vandaan komt. We hebben ons eigen stuk netwerk zo goed als uitgesloten als oorzaak.
Om het ene of het andere verder uit te sluiten gaan we de aansluiting van de eerdergenoemde Freedom medewerker verhuizen. Daarmee kunnen we weer het nodige uitsluiten (of niet). Helaas kost dat verhuistraject nog wel even wat tijd.
Zelf heb ik niet veel op met meten via een browser, veel (te veel) zaken w.o. plugins die dan kunnen inbreken of opbreken. Dat “ze” de uitkomsten in een aantrekkelijk opgemaakt plaatje rapporteren n.a.v. een asymmetrisch gestart proces, kan ik beter mee leven.
Het lastige van “performance” is ook wat de (meet)waarde daarvan met name voor wie en wat is. Best heel lastig om het als universele meetmethode te gerbuiken die dan (vaak) zelf het presentatiedoel wordt.
Zelf denk ik dat wanneer je op een 1Gbit lijn meer dan zeg 600/700Mbit hebt, de rest aan het lot der engelen kan worden ge(k)weten.
Het probleem leek opgelost na een downgrade van gigabit naar 500 mbit/s. Toch zie ik nu weer op de diverse sites zoals fast.com en speedtest.net dat upload inderdaad volledig wordt benut maar download blijft steken rond de 250 mbit/s.
Ik zie bij Freedom zelf ook een vergelijkbare uitslag waarbij download wel heel erg achterblijft.
