• Let op: Dit is het archief van het Provider Forum. De berichten die je hier ziet zijn gedateerd en er kan niet meer op worden gereageerd.

Capaciteitsproblemen Ziggo netwerk in voormalig Multikabel-gebied

  • Onderwerp starter Onderwerp starter sjaak trekhaak
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
blackhawkdesign zei:
Meerdere hops zijn bij mij traag.
Klik om te vergroten...

Een trace met pingtijden en packetloss is ook niet altijd bruikbaar om een hop aan te wijzen als problematisch. Dit omdat pingverkeer door netwerk componenten vaak genegeerd wordt als ze druk zijn. We hebben dit een paar jaar geleden ook uitgezocht samen met een technicus van Ziggo toen er problemen waren met een router in Amsterdam. Die hele grote core-routers ondersteunen (bewust) ook maar een maximaal aantal aan hen gerichte ping-requests tegelijk. De rest reageren ze niet op en gooien ze gewoon weg. Dit o.a. om crashes door DOS attacks te voorkomen. Als dus veel mensen tegelijk een traceroute of ping doen, zullen er meer pakketjes weggegooid worden dan wanneer er weinig mensen testen. (Ik dacht dat het max op 50 zat, maar dat weet ik niet zeker meer, zou ik in oude emails terug moeten zoeken).

Je herkent trouwens makkelijk of zo'n verschijnsel optreedt, want je netwerk is een 'keten' van hops. Als je op één van die hops packetloss of een hoge ping hebt, is het technisch onmogelijk dat er *achter* die hop een betere ping is of een lagere packetloss. Want als er echt packets wegraken bij 1 hop of vertragen kan het niet anders zijn dan dan het erachter dus nog (een beetje) slechter moet worden.
Dit is trouwens meestal wel te herkennen. Als de gemiddelde ping-tijd van www.ziggo.nl bijvoorbeeld 36ms is kan een eerdere hop dus nooit een hogere gemiddelde ping hebben. Als je die wel ziet (zoals in de trace die gepost werd) moet je die met een korrel zout nemen.....

Aanvulling:
Je kunt ook in DOS het commando 'pathping' gebruiken, dat is een combinatie van ping en traceroute. Default is het commando in dit geval 'pathping www.ziggo.nl' Er worden dan 100 pings per hop gedaan, dus kan het resultaat wat lang duren als er veel hops onderweg zitten.
Als je 'pathping -q 10 www.ziggo.nl ' gebruikt neemt hij maar 10 metingen per hop en duurt het testen korter (maar is het gemiddelde minder nauwkeurig). Zie voor verder info over pathping hier
 
Laatst bewerkt door een moderator:
Ik zal de resultaten van mijn pathping hier posten zodra ik er weer last van heb, momenteel is de lag opgehouden.
 
CeeS zei:
Een trace met pingtijden en packetloss is ook niet altijd bruikbaar om een hop aan te wijzen als problematisch. Dit omdat pingverkeer door netwerk componenten vaak genegeerd wordt als ze druk zijn. We hebben dit een paar jaar geleden ook uitgezocht samen met een technicus van Ziggo toen er problemen waren met een router in Amsterdam. Die hele grote core-routers ondersteunen (bewust) ook maar een maximaal aantal aan hen gerichte ping-requests tegelijk. De rest reageren ze niet op en gooien ze gewoon weg. Dit o.a. om crashes door DOS attacks te voorkomen. Als dus veel mensen tegelijk een traceroute of ping doen, zullen er meer pakketjes weggegooid worden dan wanneer er weinig mensen testen. (Ik dacht dat het max op 50 zat, maar dat weet ik niet zeker meer, zou ik in oude emails terug moeten zoeken).
Klik om te vergroten...
[offtopic]Ik kan me inderdaad nog een discussie op usenet herinneren over een stop-pinging-me router/hop ergens bij alkmaar :thankyou:[/offtopic]
 
Naja pathping geprobeerd, vanmiddag toen alles het perfect deed had ik 8 hops. Nu meet hij niet verder dan me router. De hop erna geeft immers al time outs.
 
Ik heb toch het idee dat et bij mij niet zozeer de hoge pingtijden zij maar dat er gewoon puur bandbreedte mist op drukke tijden

zoals nu:
888471011.png


Ziggo's speedtest geeft 5.0 down en 2.8 up (up is eigenlijk wel altijd prima)

Modem is ook OK volgens mij:

Downstream
Frequency 306000000 Hz
Signal to Noise Ratio 39 dB
Downstream Modulation QAM256
Network Access Control Object ON
Power Level 1 dBmV

Gateway ping:
--- 82.217.186.1 ping statistics ---
203 packets transmitted, 202 received, 0% packet loss, time 202444ms
rtt min/avg/max/mdev = 6.336/11.587/32.518/3.838 ms

Tracert is best ok als ik het vergelijk met de rest:

Tracing route to www.ziggo.nl [212.54.32.18]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.1.254
2 17 ms 8 ms 9 ms 82-217-186-1.cable.quicknet.nl [82.217.186.1]
3 20 ms 13 ms 11 ms cc27844-c.joure1.fr.home.nl [213.51.163.65]
4 20 ms 14 ms 14 ms csw1-ge2-2.ndwrt1.lb.home.nl [213.51.158.255]
5 15 ms 14 ms 15 ms 213.51.158.20
6 16 ms 17 ms 15 ms asd-lc0006-cr101-ae6-0.core.as9143.net [213.51.158.78]
7 22 ms 18 ms 15 ms gn-rc0002-cr101-ae0-0.core.as9143.net [213.51.158.143]
8 23 ms 14 ms 14 ms gn-rc0001-ds113-te1-1.groni1.gr.home.nl [213.51.158.127]
9 16 ms 12 ms 13 ms www.ziggo.nl [212.54.32.18]
 
Laatst bewerkt door een moderator:
100 pings naar gateway:
Code: 
Ping-statistieken voor 84.104.121.1:
    Pakketten: verzonden = 100, ontvangen = 98, verloren = 2
    (2% verlies).
De gemiddelde tijd voor het uitvoeren van één bewerking in milliseconden:
    Minimum = 10ms, Maximum = 1644ms, Gemiddelde = 84ms
tracert:
Code: 
Traceren van de route naar [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
via maximaal 30 hops:
  1   <1 ms   <1 ms   <1 ms  router [192.168.1.1]
  2   209 ms    37 ms     *     84-104-121-1.cable.quicknet.nl [84.104.121.1]
  3    65 ms    20 ms     *     cc431342-a.joure1.fr.home.nl [213.51.163.33]
  4    62 ms    90 ms     *     213.51.158.120
  5   143 ms    42 ms   347 ms  asd-lc0006-cr101-ae6-0.core.as9143.net [213.51.158.78]
  6    18 ms    29 ms     *     gn-rc0002-cr101-ae0-0.core.as9143.net [213.51.158.143]
  7    24 ms    18 ms     *     gn-rc0001-ds113-te1-1.groni1.gr.home.nl [213.51.158.127]
  8    47 ms    61 ms     *     [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
  9    30 ms    66 ms   151 ms  [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
pathping:
Code: 
C:\Windows\system32>pathping -q 10 [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL]
Traceren van de route naar [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
via maximaal 30 hops:
  0  local [192.168.1.104]
  1  router [192.168.1.1]
  2  84-104-121-1.cable.quicknet.nl [84.104.121.1]
  3  cc431342-a.joure1.fr.home.nl [213.51.163.33]
  4     *     213.51.158.120
  5  asd-lc0006-cr101-ae6-0.core.as9143.net [213.51.158.78]
  6  gn-rc0002-cr101-ae0-0.core.as9143.net [213.51.158.143]
  7     *     gn-rc0001-ds113-te1-1.groni1.gr.home.nl [213.51.158.127]
  8  [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
Statistieken worden nu gedurende een periode van 20 seconden berekend...
            Van bron - hier  Dit knooppunt / deze verbinding
Hop  RTT    Verl./verzonden  Verloren/verz.   Adres
  0                                           local [192.168.1.104]
                                0/  10 =  0%   |
  1    1ms     0/  10 =  0%     0/  10 =  0%  router [192.168.1.1]
                                0/  10 =  0%   |
  2   96ms     1/  10 = 10%     1/  10 = 10%  84-104-121-1.cable.quicknet.nl [84.104.121.1]
                                0/  10 =  0%   |
  3   52ms     0/  10 =  0%     0/  10 =  0%  cc431342-a.joure1.fr.home.nl [213.51.163.33]
                                0/  10 =  0%   |
  4  173ms     0/  10 =  0%     0/  10 =  0%  213.51.158.120
                                0/  10 =  0%   |
  5   96ms     0/  10 =  0%     0/  10 =  0%  asd-lc0006-cr101-ae6-0.core.as9143.net [213.51.158.78]
                                0/  10 =  0%   |
  6  129ms     2/  10 = 20%     2/  10 = 20%  gn-rc0002-cr101-ae0-0.core.as9143.net [213.51.158.143]
                                0/  10 =  0%   |
  7  155ms     0/  10 =  0%     0/  10 =  0%  gn-rc0001-ds113-te1-1.groni1.gr.home.nl [213.51.158.127]
                                0/  10 =  0%   |
  8  144ms     0/  10 =  0%     0/  10 =  0%  [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
De trace is voltooid.

modem status:
modem.jpg

Mij valt de upstream channel type op.. hoort dit niet ATDMA te zijn?
 
Hier ook niet best, zeker rond deze tijd in de avond

Code: 
Pinging [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18] with 32 bytes of data:
Reply from 212.54.32.18: bytes=32 time=424ms TTL=249
Reply from 212.54.32.18: bytes=32 time=333ms TTL=249
Reply from 212.54.32.18: bytes=32 time=27ms TTL=249
Reply from 212.54.32.18: bytes=32 time=770ms TTL=249
Ping statistics for 212.54.32.18:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 770ms, Average = 388ms

Code: 
Tracing route to [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 53 ms 48 ms 43 ms 212-127-182-1.cable.quicknet.nl [212.127.182.1]
3 263 ms 70 ms 198 ms ubr2-bu3-sec.joure1.fr.home.nl [213.51.164.1]
4 67 ms 72 ms 62 ms asd-lc0006-cr101-ae6-0.core.as9143.net [213.51.1
58.78]
5 163 ms 165 ms 127 ms gn-rc0002-cr101-ae0-0.core.as9143.net [213.51.15
8.143]
6 1153 ms 18 ms * gn-rc0001-ds113-te1-1.groni1.gr.home.nl [213.51.
158.127]
7 60 ms 27 ms 19 ms [URL="https://www.ziggo.nl"]www.ziggo.nl[/URL] [212.54.32.18]
Trace complete.

 
trace om 21:15 vanavond

1 <1 ms <1 ms <1 ms 192.168.1.1
2 129 ms 58 ms 18 ms 84-104-129-1.cable.quicknet.nl [84.104.129.1]
3 47 ms 29 ms 40 ms ubr2-bu3-sec.joure1.fr.home.nl [213.51.164.1]
4 151 ms 99 ms 18 ms asd-lc0006-cr101-ae6-0.core.as9143.net [213.51.1
58.78]
5 39 ms 63 ms 22 ms gn-rc0002-cr101-ae0-0.core.as9143.net [213.51.15
8.143]
6 134 ms 50 ms 29 ms gn-rc0001-ds113-te1-1.groni1.gr.home.nl [213.51.
158.127]
7 25 ms 108 ms 99 ms www.ziggo.nl [212.54.32.18]

Zoals ik al eerder meldde, de 2e hop is de boosdoener...


Over die betere waarden bij verdere hops, ik ben geen expert, dus correct me if i am wrong.. ik leer graag bij.
Is dat niet gewoon het gevolg van het feit dat de ping-requests niet gelijktijdig worden gedaan maar dat er wel een sterk over de tijd fluctuerende latency bestaat op de tweede hop (of een van de eerdere hops)?? Als bv. er een latency spike voorbij komt ten tijde van je ping naar je 2e hop en deze verbetert op het moment dat er een ping wordt gestuurd naar je 6e hop (en die loopt uiteraard over je 2e hop), dan lijkt het alsof de ping naar je 6e hop beter is dan naar de 2e hop... je kunt met deze methode dus hooguit statistisch aantonen, mits lang genoeg getest, waar de echte vertraging optreedt.
Echter het donkerbruine vermoeden is dat de vertragingen optreden in de eerste hop buiten je huis (router, hub, cmts, gateway, wie de juiste naam weet mag het zeggen). Door specifiek dit adres te pingen over een langere periode kun je dit valideren of afstrepen...

Ik wil iedereen er bovendien nog even op wijzen dat de latency sterk fluctueert over de dag heen, een paar goede pingtests zegt niet zoveel... zelfs niet tijdens piekuren! ook dan kun je korte perioden een prachtige latency hebben...

Dat van stop-pinging-me is natuurlijk altijd mogelijk, maar ik zie bij mij in ieder geval een duidelijk verband tussen het niet kunnen draaien van toepassingen en een slechte ping... daarom sluit ik het voor mijn situatie uit.


@phosidon: kan ik velserbroek hierbij op het lijstje zetten? je resultaat lijkt er nl. wel naar...
 
Laatst bewerkt door een moderator:
sjaak trekhaak zei:
Is dat niet gewoon het gevolg van het feit dat de ping-requests niet gelijktijdig worden gedaan maar dat er wel een sterk over de tijd fluctuerende latency bestaat op de tweede hop (of een van de eerdere hops)?? Als bv. er een latency spike voorbij komt ten tijde van je ping naar je 2e hop en deze verbetert op het moment dat er een ping wordt gestuurd naar je 6e hop (en die loopt uiteraard over je 2e hop), dan lijkt het alsof de ping naar je 6e hop beter is dan naar de 2e hop... je kunt met deze methode dus hooguit statistisch aantonen, mits lang genoeg getest, waar de echte vertraging optreedt.
Echter het donkerbruine vermoeden is dat de vertragingen optreden in de eerste hop buiten je huis (router, hub, cmts, gateway, wie de juiste naam weet mag het zeggen). Door specifiek dit adres te pingen over een langere periode kun je dit valideren of afstrepen...
Klik om te vergroten...

Pings naar alles wat verder is dan de 2e hop lopen altijd ook via die tweede hop. dus als je statistisch alleen meer delay hebt in de tweede hop, maar niet in de bijvoorbeeld laatste hop bewijs je daarmee dat er in werkelijkheid geen latency-spike bestaat, maar dat de tweede hop het gewoon te druk heeft en het antwoord op de ping uitstelt ten opzichte van het andere verkeer. Dit is overigens wel een indicatie dat de tweede hop (=je CMTS) het druk heeft.

Ik denk dat de problemen die je nu in Noordholland ziet grotendeels te wijten zijn aan het feit dat er daar nog oude cmts'en staan die op hun tenen draaien omdat het drukker wordt. Ik begreep een aantal weken terug dat vanaf augustus die CMTS'sen vervangen worden. Aangezien het er nogal wat zijn en er maar een beperkt aantal werkbare nachten per week zijn wel een paar maanden kan duren voordat ze allemaal vervangen zijn. Of je last van de drukte hebt is helemaal afhankelijk van welk CMTS je op zit. Sommige gemeentes hebben meerdere cmts'sen en soms werkt de ene snel en de andere niet, vandaar dat je ook in zelfde gemeentes soms verschillende resultaten ziet.

Als je bij je upload 2560 ksym/sec ziet staan ipv de normaal 5120, wil het zeggen dat je upload niet op maximale snelheid schakelt. Dat kan aan kwaliteit van je signaal liggen door ruis of een te zwak signaal. Het modem schakelt dan terug naar een lagere snelheid om verbinding te houden. Dit hangt ook af van het CMTS waar je op zit.

Ben benieuwd of Ziggo zelf nog iets kan vinden als generieke oorzaak van dit probleem, of dat het toch alleen maar de CMTS'sen zijn die de boel beperken als het druk wordt.
 
thnx voor de uitleg Cees

denk je dat in het laatste geval het voor Ziggo mogelijk is om bepaalde cmts'en met voorrang te vervangen ?... :cool:
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan