Latency voordeel van glasvezel (?)

[Anoniem: 294474]

Een veelgehoord argument om te kiezen voor een glasvezelaansluiting (fiber to the home) is een lagere latency / pingtijd . Bij het glasvezelcongress 'light my fibre' afgelopen week werd dit weer breed naar voren gebracht.

Mijn vraag aan jullie is wat de ervaringen hiermee zijn. Welke ping tijden ervaren jullie bij een ping naar een veel gebruikte dienst als nu.nl?

Zelf zit ik op Ziggo (voorheen Multikabel). Ping naar nu.nl geeft een round trip delay van 9-12 ms.

Als je op glas zit, post dan svp even jouw waarde. Je mag mij uiteraard ook verwijzen naar online meetresultaten.

[bosch007]

Hier in Dordrecht ben ik van +/- 25 ms naar 4 ms gegaan (ping naar tweakers.net).
Dit is met FTTO 50/50 Mbit van KPN.

[painkill]

In veel gevallen maakt het weinig uit, de hardware van je pc geeft latency, en ook de afstand en hardware van de ontvanger maakt heel wat uit.

Betekend niet dat je geen winst kun boeken met glas,dit zeker wel.

[itons]

Ik zou niet weten wat het voordeel hiervan is, voor browsen is de lagere latency totaal niet interessant, websites zullen niet merkbaar sneller op je scherm komen, het gaat hier om veel te kleine vertragingen om er maar iets van te merken.

[Boudewijn]

Voor gamers is het wel relevant, vinden ze zelf .

[itons]

Boudewijn schreef op maandag 09 maart 2009 @ 14:39:
Voor gamers is het wel relevant, vinden ze zelf .

Ik speel zelf al tijden op glasvezel en ping <1 is leuk, maar gezien de reactie tijd van de mens is het verschil tussen ADSL (30ms) en glas natuurlijk te verwaarlozen. Wel leuk om mensen te neten ermee en te zeggen dat je ping hacks hebt, maar dat is weer een ander verhaal

[d0s]

Thuis (Chello) haal ik zo'n 20/30/40 ms op mijn laptop, waar ik in Nijmegen (XMSnet) 6 of 7 haal.
Ik merk daar duidelijk verschil in, met gamen dan he

[ACM]

Wij zijn bij ons op kantoor ook van gemiddeld zo'n 25ms naar 2ms naar de tweakers.net-webservers gegaan, maar daarbij scheelt het dat de daadwerkelijke netwerkroute enorm gedaald naar 3 stappen; gateway hier, gateway daar en dan de uiteindelijke server

De belangrijkste reden waarom latency ook voor website-bezoek niet zomaar genegeerd moet worden is dat je doorgaans meerdere requests per pagina doet en dan is de winst per complete pageview al gauw interessant natuurlijk. Worst case kan je binnen nederland zomaar van 50*25 naar 50*5 ms gaan en dan is het een volle seconde winst in laadtijd. In de praktijk zal dat uiteraard meestal minder sterk gebeuren.

[Robinski]

Een volle seconden wint is natuurlijk wel erg mooi!

Overigens is volgens mij het grootste voordeel voor glasvezel gewoon de mogelijke bandbreedte die beschikbaar is, waardoor er gewoon vele male meer data doorgegeven kan worden.

[ralpje]

Daarnaast is een lagere latency natuurlijk prettig bij bijvoorbeeld VoIP, al zal dat in thuissituaties niet snel relevant zijn.

[michelc85]

Heb hier een ping tijd van 3ms naar nu.nl , met glasvezel van xms in leiden

[Anoniem: 76287]

Dat is wel netjes. Met ADSL hier zit ik op bijna alle sites met 15ms. Maakt die 12ms (of factor 5!) nog veel uit? Ik doe niet veel online games waarbij de reactietijd van belang is en 15ms vind ik uitstekend.

[tjtristan]

michelc85 schreef op maandag 09 maart 2009 @ 19:53:
Heb hier een ping tijd van 3ms naar nu.nl , met glasvezel van xms in leiden

sjezus, ik mag blij zijn als ik dat op m'n private netwerk haal

[Kokkers]

ACM schreef op maandag 09 maart 2009 @ 15:03:
Worst case kan je binnen nederland zomaar van 50*25 naar 50*5 ms gaan en dan is het een volle seconde winst in laadtijd. In de praktijk zal dat uiteraard meestal minder sterk gebeuren.

Ik snap je punt maar ik ga er vanuit dat dat een moderne browser zijn requestqueue niet sequentieel doorloopt. De seconde winst uit je voorbeeld is misschien iets te rooskleurig.

/edit
(Toch maar even uitzoeken voordat ik blaat)

Browsers typically limit the number of concurrent HTTP connections per server to be 2(the term “per server" is used broadly here for the sake of simplicity. For example, it could be multiple physical machines sharing the same public IP.). If a browser session has two HTTP connections already, any further connection requests will have to wait until one of these two HTTP connections is finished.

Bij een voorbeeld van 50 requests per pagina is de snelheidswinst default dus 0,5 seconde
Dit zou zeker merkbaar moeten zijn.

(lijkt me dus sowieso een goede tweak om op je systeem de default van max 2 concurrent connections op te hogen)

Propagation speed is affected by insulation, such that in an unshielded copper conductor it is about 96% of the speed of light, while in a typical coaxial cable it is about 66% of the speed of light.

Worst case is (coax) kabel dus 33% trager (latency) dan fiber, in de praktijk zal dit snelheidsverschil veel kleiner zijn omdat waarschijnlijk maar een klein gedeelte van het pad (coax) kabel bevat en het tussengedeelte ook over fibers loopt.

Ik denk dat de beperkte hoeveelheid 'hops' van moderne fiberaansluitingen de grootste snelheidswinst geeft.
Kan iemand met kennis van zaken toelichten hoe de architectuur van een 'fiber to the home' netwerk er uit ziet? Glas in je modem in je meterkast, waar komt dit glas vervolgens uit? Wijkcentrum? Wat voor een hardware hangt hier achter?

[ACM]

Kokkers schreef op maandag 09 maart 2009 @ 20:21:
Ik snap je punt maar ik ga er vanuit dat dat een moderne browser zijn requestqueue niet sequentieel doorloopt. De seconde winst uit je voorbeeld is misschien iets te rooskleurig.

Daarom gaf ik ook "worst case" erbij, normaliter is er ook nog wel zoiets als "Keep-Alive" wat de connectie-latency zou moeten verbeteren/wegnemen (maar de verdere request/response-latency niet) en HTTP Pipelining (wat vziw default uitstaat bij de diverse browsers). Hoedanook, het zijn geen enorme verschillen in de praktijk, maar "het maakt geen bal uit" is waarschijnlijk weer net wat te ver de andere kant op