Snelheid afhankelijk van IP-range?
Geplaatst: 23 apr 2004, 15:14
Hi,
(1)miss niet zo zeer A2F related, ma kzit nu eenmaal op A2F dus..
Sinds vandaag laat ik ProviderTest.be om het uur (automatisch) m'n downloadsnelheid checken.
Nu bleek ik dus in de loop van de dag in een andere range te belanden (weet niet in dewelke ik dervoor zat, maar nu: 81.89.99.xx).
Snelheid met 'vorig' ip (was iets van 81.89.238??.xx): 343 - 454 kbps
Snelheid met 'nieuw' ip (81.89.99.xx): 46kbps - 173kbps
Miss is mijn kennis in dit gebied ontoereikend (wrs
), maar heeft iemand hier een verklaring voor?
(2)Wel A2F related, ma pls no flaming kdacht miss hebben ze der iets aan (wrs ni ). Met die snelheid verandering in punt (1) hebbek wa zitten testen en dit zijn de conclusies:
Vertraging treedt op bij
->tracert naar webvisie (dus op zelfde netwerk): rt7204-gw.net4all.net ('vertraging' is in dit geval een groot woord)
->tracert naar scarlet (in principe ook op zelfde netwerk): gig-0-1-ia-be-bru-ar01.KPNbelgium.be
->tracert naar belnet (eigenlijk maar 1 stapje verder naar het internet): gig-0-1-ia-be-bru-ar01.KPNbelgium.be
->tracert naar kpn.nl (moederbedrijf):
gig-0-1-ia-be-bru-ar01.KPNbelgium.be en alle daaropvolgende hops (alle hops zijn KNP-owned)
->tracert naar telenet/skynet/xs4all(be/nl): gig-0-1-ia-be-bru-ar01.KPNbelgium.be
Dus blijkt toch dat de bottleneck KPN-owned is, ik neem aan dat dit wel de link van Net4All (webvisie) naar de KPN backbone is daar de laatste hop voor de bottleneck nog Net4All-owned is.
De lijnen van Net4All lijken dus in orde (laat ons niet discussieren over hoe het komt dat de backbone een bottleneck is), rest mij dus nog enkel de vraag uit punt (1)
.
En dan ben ik HELEMAAL overtuigd dat de A2F infrastructuur in orde is (blijft wel de backbone die ons dwingt door een rietje te zuigen ipv 'aan-den-teut-te-zabberen' maar dan willek nog wel geloven dat KPN de schuldige is).
Thx,
UC
(1)miss niet zo zeer A2F related, ma kzit nu eenmaal op A2F dus..
Sinds vandaag laat ik ProviderTest.be om het uur (automatisch) m'n downloadsnelheid checken.
Nu bleek ik dus in de loop van de dag in een andere range te belanden (weet niet in dewelke ik dervoor zat, maar nu: 81.89.99.xx).
Snelheid met 'vorig' ip (was iets van 81.89.238??.xx): 343 - 454 kbps
Snelheid met 'nieuw' ip (81.89.99.xx): 46kbps - 173kbps
Miss is mijn kennis in dit gebied ontoereikend (wrs
), maar heeft iemand hier een verklaring voor?(2)Wel A2F related
, ma pls no flaming kdacht miss hebben ze der iets aan (wrs ni ). Met die snelheid verandering in punt (1) hebbek wa zitten testen en dit zijn de conclusies:Vertraging treedt op bij
->tracert naar webvisie (dus op zelfde netwerk): rt7204-gw.net4all.net ('vertraging' is in dit geval een groot woord)
->tracert naar scarlet (in principe ook op zelfde netwerk): gig-0-1-ia-be-bru-ar01.KPNbelgium.be
->tracert naar belnet (eigenlijk maar 1 stapje verder naar het internet): gig-0-1-ia-be-bru-ar01.KPNbelgium.be
->tracert naar kpn.nl (moederbedrijf):
gig-0-1-ia-be-bru-ar01.KPNbelgium.be en alle daaropvolgende hops (alle hops zijn KNP-owned)
->tracert naar telenet/skynet/xs4all(be/nl): gig-0-1-ia-be-bru-ar01.KPNbelgium.be
Dus blijkt toch dat de bottleneck KPN-owned is, ik neem aan dat dit wel de link van Net4All (webvisie) naar de KPN backbone is daar de laatste hop voor de bottleneck nog Net4All-owned is.
De lijnen van Net4All lijken dus in orde (laat ons niet discussieren over hoe het komt dat de backbone een bottleneck is), rest mij dus nog enkel de vraag uit punt (1)
.En dan ben ik HELEMAAL overtuigd dat de A2F infrastructuur in orde is (blijft wel de backbone die ons dwingt door een rietje te zuigen ipv 'aan-den-teut-te-zabberen' maar dan willek nog wel geloven dat KPN de schuldige is).
Thx,
UC