XMS snelheid tijdens piekuren

[Verwijderd]

Er bestaat al een topic over de XMS glasvezelervaringen, maar het leek mij leuk om hier eens de ervaringen met de snelheid van iedereen te verzamelen. Ik heb sinds begin deze week glasvezel van XMS (overstap van UPC fiberpower 120) en ik moet zeggen dat ik diep teleur gesteld ben in de kwaliteit van het XMS netwerk:

Hieronder wat resultaten (wget -O /dev/null average over files van 250-1000MB)

Leaseweb NL mirror: 24/12 om 19:20: 2,01MB/s
Leaseweb NL mirror: 25/12 om 11:49: 11,2MB/s

Leaseweb DE mirror: 24/12 om 19:24: 680KB/s
Leaseweb DE mirror: 25/12 om 11:50: 10,8MB/s

Leaseweb US mirror: 24/12 om 19:34: 172KB/s
Leaseweb US mirror: 25/12 om 11:51: 10,7MB/s

En bijvoorbeeld een wgetje vanaf mijn eigen server (1GE volledig idle) gaf op 24/12 om 20:16 slechts 4,52MB/s gemiddeld...

Wat ik uit deze resultaten haal is dat XMS op de backbone volgens mij een licht capaciteitsprobleempje heeft. Als ik namelijk test via m'n oude fiber power die nog actief is, haal ik op zulke dieptemomenten soms wel het 5 voudige ten opzichte van XMS.

Ben benieuwd of meer mensen dit ervaren, want de beloftes die XMS op de website maakt (geen merkbare invloed als er meerdere mensen online zijn enz.) worden niet echt waar gemaakt...

[Verwijderd]

Hier worden ze al wel sinds jaar en dag waar gemaakt. Nooit problemen met de snelheid en ik up- en download mezelf helemaal de rambam.

[White_Collar]

Normaal hoor je ook tijdens piek uren gewoon de snelheid te halen en moet dat geen probleem te zijn voor XMS.
Echter lijkt het erop dat er ergens in het netwerk niet helemaal goed gaat zoals je ook kan zien.
Het beste wat je kan doen is om toch dit probleem even te posten in het grote xms topic:
XMS Glasvezel ervaring - XIV

Daar zit onder andere het webcare team van XMS en een paar medewerkers (zoals ik) en zeer deskundige eindgebruikers waar we het probleem verder kunnen analyseren en oplossen.
Post direct even een trace mee naar je server + postcode als je de post opnieuw in het xms topic plaatst.

[ Voor 9% gewijzigd door White_Collar op 26-12-2011 17:56 ]

[Verwijderd]

Heb al n mailtje naar [e-mail] ingeschoten met allerlei data. Heb ook nog wel een mtr voor de liefhebber. Het lijkt toch echt middenin het XMS (internl.net) netwerk mis te gaan in de zin van latency. De hop erna is nog wel weer goed, alleen op momenten dat er zich geen snelheidsproblemen voordoen is die enorme latency rondom vlan51 er niet. Wel is er op de tweede hop altijd flinke packetloss maar dat lijkt een ICMP rate limit te zijn want na die hop is er geen loss meer...

[ Voor 63% gewijzigd door Verwijderd op 26-12-2011 18:58 ]

[White_Collar]

Ik schat in dat er toch een noc ticket geschreven gaat worden.
Ik zou als ik jou was deze post toch even in de xms topic gooien, dan zal webcare daar waarschijnlijk wel op reageren

[Verwijderd]

@timvdl Volgens mij heb ik al eens eerder een heel verhaal hierover geschreven.. Wat jij met mtr ziet zijn de tijden die de verschillende hops er over doen om een icmp bericht terug te sturen omdat de ttl verlopen is. icmp wordt door veel routers met hele lage prio doorgegeven of zelfs genegeerd.
Je zou mtr -u kunnen proberen (doet UDP), maar dan nog test je eigenlijk alleen maar hoe snel de router je packet terugstuurt omdat de ttl verlopen is, dus niet hoe snel hij het doorgeeft.

Even ter vegelijking, bij mij doet een mtr -u hetzelfde.. Ik zie ook hoge avg (doordat er af en toe een response van 200ms is)

1. 1-48-223.ftth.xms.internl.net 0.0% 59 0.3 0.4 0.3 1.2 0.1
2. ???
3. ???
4. ???
5. ???
6. ???
7. vlan335.newxr1.nik-asd.internl.net 0.0% 58 2.5 8.1 2.4 178.1 28.1
8. vlan51.newxr2.nik-asd.internl.net 0.0% 58 2.5 20.0 2.5 188.8 45.6
9. GigabitEthernet6-2.ar7.AMS2.gblx.net 0.0% 58 2.7 10.9 2.6 144.3 28.1
10. ae2.scr2.AMS2.gblx.net 0.0% 58 2.6 5.2 2.5 39.8 7.0
11. ae10.scr4.FRA4.gblx.net 0.0% 57 8.9 9.1 8.8 19.3 1.5
12. lag2.ar4.fra4.gblx.net 0.0% 57 17.8 11.3 8.9 19.8 3.6
13. FIBERRING-B-V.ethernet2-2.csr1.FRA4.gblx.net 0.0% 57 145.9 21.4 9.4 363.4 51.0
FIBERRING-B-V.ethernet3-1.csr1.FRA4.gblx.net
fibberring.ethernet14-3.ar4.fra4.gblx.net
14. mirror.de.leaseweb.net 0.0% 57 9.8 9.8 9.6 10.2 0.1


En bij mij is de snelheid wel in orde (50mbit/s +). Wat me wel opvalt is de hoge packetloss op jouw modem.. die 95% Dat geeft toch wel aan dat daar iets mis is.. is je modem al eens vervangen?

[ Voor 59% gewijzigd door Verwijderd op 28-12-2011 13:30 ]

[bjck]

Verwijderd schreef op woensdag 28 december 2011 @ 12:15:

[...]

En bij mij is de snelheid wel in orde (50mbit/s +). Wat me wel opvalt is de hoge packetloss op jouw modem.. die 95% Dat geeft toch wel aan dat daar iets mis is.. is je modem al eens vervangen?

Die 95% loss is puur verkeer aan je router gericht door de TTL. Die moet antwoorden en doet dit niet voor alle packets, geen enkel probleem. Je ziet immers dat op het eind station alle packets voor dat station bedoeld zijn aangekomen en beantwoord.

Onderweg een router die packetloss geeft dat op het eindstation 0% loss geeft is geen verloren pakket. Maar een door de router zelf niet beantwoord pakket. De rest routeert hij prima anders had je op het eind station ook minimaal 95% gezien.

[Verwijderd]

Nou, ik heb van XMS een reactie op het onderzoek dat uitgevoerd is:
Omdat de snelheid met de Reggefiber test goed is (lokale test) is het netwerk oké claimen ze. Tot zover kan ik akkoord gaan. Verder is er dus niets waar zij invloed op hebben zegt XMS:

-----------------------------------------------------------------------------
Conclusie:
Wij zien geen problemen binnen ons netwerk.
Wanneer je 's avonds een lagere downloadsnelheid behaalt met een server in New York (of Duitsland) kan dit te wijten zijn aan externe factoren.
Dit kan veroorzaakt worden door een probleem bij de andere provider of de AMS-IX.
-----------------------------------------------------------------------------

Ik ben toch van mening dat XMS een zekere overboeking hanteert en dat ik in de avonduren redelijke peerings moet kunnen verwachten die niet compleet overloaded zijn? Ik gebruik in al mijn tests als voorbeeld even Leaseweb mirrors maar ook naar mirrors van andere providers is de snelheid slecht, de NY test van Reggefiber laat in de avond ook een flink verschil zien. Omdat het via verschillende andere ISPs wel snel werkt lijkt het toch vrij simpel mis te gaan bij de peerings van XMS.

Omdat ik een beetje cynisch word van dit soort antwoorden (ik weet het, het is offtopic) wil ik hieronder graag even mijn Vodafone 3G vs XMS 100mbit glas compilatie laten zien tijdens de avonduren. De winnaar is natuurlijk de 3G verbinding via Vodafone... Wat niet zo zou moeten zijn... Owja, vergeet ik te zeggen dat m'n vrienden via Tele2 ADSL, KPN ADSL, UPC & Ziggo minstens 1MB/s of hoger halen van dezelfde mirror op dezelfde momenten




Uiteraard heb ik XMS natuurlijk dus ook weer een reactie teruggestuurd met de vraag nog eens serieus naar dit probleem te kijken omdat deze manier van het afhandelen van zulke problemen niet echt de manier is naar mijn idee...

Update: Als er positieve ontwikkelingen zijn wil ik die natuurlijk ook graag melden en niet alleen de negatieve: XMS geeft mij gezien de peering-issues die ik ondervind de mogelijkheid om het contract vroegtijdig te ontbinden en een andere ISP te zoeken die wel voldoet. Keurige service in dat opzicht en jammer dat de oorzaak niet opgelost is, maar dat ik nu toch van het probleem verlost ben. Dat is toch zeker een vorm van meedenken met de klant

[ Voor 36% gewijzigd door Verwijderd op 07-01-2012 00:49 ]

[White_Collar]

Spijtig dat je contract is opgezet omdat het probleem nu waarschijnlijk is opgelost:

--->Verwijderd in "XMS Glasvezel ervaring - XIV"

[Verwijderd]

Dat is dan inderdaad jammer. Zeker omdat glas-glas overstappen erg lastig is... Bijna geen enkele ISP kan dat nog dus ben daar aardig mee aan het worstelen Wel vraag ik me af of ik bij een provider wil blijven die na netwerkonderzoek terugstuurt dat er niets is terwijl er wel degelijk iets was... Als mij was verteld: Tim, er zijn wat issues, het kan even duren, maar we're working on it... Prima Dan wacht ik rustig af...

Overigens: het gaat nu inderdaad snel... Dus het lijkt inderdaad opgelost...

[ Voor 8% gewijzigd door Verwijderd op 12-01-2012 22:12 ]

[denan]

Verwijderd schreef op donderdag 12 januari 2012 @ 22:12:
Dat is dan inderdaad jammer. Zeker omdat glas-glas overstappen erg lastig is... Bijna geen enkele ISP kan dat nog dus ben daar aardig mee aan het worstelen Wel vraag ik me af of ik bij een provider wil blijven die na netwerkonderzoek terugstuurt dat er niets is terwijl er wel degelijk iets was... Als mij was verteld: Tim, er zijn wat issues, het kan even duren, maar we're working on it... Prima Dan wacht ik rustig af...

Het probleem ontstond buiten het netwerk dat bekeken werd dus dat is heel logisch. Ook was het een bug in linecard waardoor deze slechts 40-45% van de totale capaciteit wilde gebruiken. Netwerkcapaciteit voldoende volgens de monitoring en dan is de eerste reactie "er is niets met de capaciteit aan de hand". Dat wil echter niet zeggen dat men op de achtergrond niet door gaat zoeken.