• 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.

Packet Lose Heerlen Limburg

  • Onderwerp starter Onderwerp starter Rogi
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
R

Rogi

Packet Lose Molenberg, Heerlen, Limburg

Sinds een paar dagen heb ik last van nogal hoge packet lose. Het maakt gamen en normaal internet nogal traag en onhandelbaar, vooral het online gamen (rubberbanding, lag spikes, noem maar op). Modem reset gedaan, geef effect.

Naar google dns.
Code: 
admin@RT-N66U:/jffs/configs# ping -q 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
1405 packets transmitted, 1254 packets received, 10% packet loss
round-trip min/avg/max = 10.774/16.134/36.874 ms
Naar gateway.
Code: 
admin@RT-N66U:/jffs/configs# ping -q 84.25.28.1
PING 84.25.28.1 (84.25.28.1): 56 data bytes

--- 84.25.28.1 ping statistics ---
920 packets transmitted, 829 packets received, 9% packet loss
round-trip min/avg/max = 4.679/7.348/26.403 ms
Code: 
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
  0  Igor-Desktop [192.168.1.134] 
  1  router.asus.com [192.168.1.1] 
  2     *     10.228.52.1 
  3  venl-rc0003-cr102-xe-1-2-0-0.core.as9143.net [213.51.187.26] 
  4     *     asd-tr0610-cr101-ae4-0.core.as9143.net [213.51.160.216] 
  5  72.14.222.56 
  6  209.85.240.63 
  7  66.249.94.167 
  8  209.85.253.201 
  9  216.239.48.31 
 10     *        *        *     
Computing statistics for 225 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           Igor-Desktop [192.168.1.134] 
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  router.asus.com [192.168.1.1] 
                                9/ 100 =  9%   |
  2  ---     100/ 100 =100%    91/ 100 = 91%  10.228.52.1  <---- blokkeert icmp packets?
                                0/ 100 =  0%   |
  3    9ms     9/ 100 =  9%     0/ 100 =  0%  venl-rc0003-cr102-xe-1-2-0-0.core.as9143.net [213.51.187.26] 
                                3/ 100 =  3%   |
  4   14ms    12/ 100 = 12%     0/ 100 =  0%  asd-tr0610-cr101-ae4-0.core.as9143.net [213.51.160.216] 
                                1/ 100 =  1%   |
  5   12ms    13/ 100 = 13%     0/ 100 =  0%  72.14.222.56 
                                2/ 100 =  2%   |
  6   12ms    15/ 100 = 15%     0/ 100 =  0%  209.85.240.63 
                               85/ 100 = 85%   |
  7  ---     100/ 100 =100%     0/ 100 =  0%  66.249.94.167 
                                0/ 100 =  0%   |
  8  ---     100/ 100 =100%     0/ 100 =  0%  209.85.253.201 
                                0/ 100 =  0%   |
  9  ---     100/ 100 =100%     0/ 100 =  0%  216.239.48.31 

Trace complete.
Packet lose is voor vrijwel elke publieke ip hetzelfde, rond de 7%-10%. En nee, dit is niet over wifi.
 
Laatst bewerkt door een moderator:
Packetloss is lastig te meten, want je weet nooit of het 'echte' packetloss is of dat de node die je test icmp packets weggooit als hij het druk heeft.

Je ziet dat mooi aan de tabel die je zelf meestuurt. Daar zitten een aantal nodes bij die helemaal niet reageren op pings, maar er zijn ook een aantal waar je een paar procent verlies hebt, de hops die 'daarachter' zitten hebben dan weer nul procent loss. En dat is onmogelijk als op de eerdere hops echt packetloss zou zitten. Alle pakketjes gaan namelijk van hop-naar-hop en de loss zou op moeten tellen als het 'echte packetloss is'. Dus achter een hop waar je 5% loss hebt zou je minimaal ook 5% moeten blijven meten. In je voorbeeld heb je dus bij hop-9 nul procent loss, dus in de totale keten die via hop 1 tot hop 9 loopt. Dat geeft aan dat de tussenliggende hops icmp/pings weggooien als ze het druk hebben.

Weggooien van ping-verkeer is niet vreemd en daarom kun je ping dus eigenlijk niet echt gebruiken om een conclusie te trekken waar je rubberbanding vandaan komt. Voor een end-to-end test is het wel bruikbaar, mits de eindnode geen pings bewust weggooit. Dat laatste weet je vrijwel nooit zeker.
 
Mijn eerste hop heeft al packet loss; de gateway die ik via DHCP krijg toegewezen door Ziggo. Dit probleem had ik een paar dagen geleden niet, toen liep alles ok. Maar sinds een paar dagen gaat alles maar traag en stotterend. Aan mijn kant is niks veranderd.

Code: 
admin@RT-N66U:/tmp/home/root# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
84.25.28.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
84.25.28.0      0.0.0.0         255.255.254.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         84.25.28.1      0.0.0.0         UG    0      0        0 eth0
Code: 
admin@RT-N66U:/tmp/home/root# ping -q 84.25.28.1
PING 84.25.28.1 (84.25.28.1): 56 data bytes

--- 84.25.28.1 ping statistics ---
221 packets transmitted, 199 packets received, 9% packet loss
round-trip min/avg/max = 4.546/6.968/22.692 ms
Nou zie ik dat het "wijk kastje op de hoek" omheen ge'taped is als of hij open geweest is of beschadigd. Dit is sinds een paar dagen. Ik ben nu maar gewoon hard op aan het denken voor een reden waar dit vandaan kan komen. :rolleyes:
 
Laatst bewerkt door een moderator:
Je zou eens naar de signaalstatus van je modem kunnen kijken. Zie je veel uncorrectables of T3-timeouts dan is er mogelijk iets mis met de verbinding van je modem met het CMTS.
 
Ziet er naar uit dat het probleem is opgelost op dit moment.

Code: 
admin@RT-N66U:/tmp/home/root# ping -q 84.25.28.1
PING 84.25.28.1 (84.25.28.1): 56 data bytes

--- 84.25.28.1 ping statistics ---
405 packets transmitted, 403 packets received, 0% packet loss
round-trip min/avg/max = 3.405/6.441/22.658 ms

Dit ziet er al beter uit.
 
Rogi zei:
Mijn eerste hop heeft al packet loss; de gateway die ik via DHCP krijg toegewezen door Ziggo.
Klik om te vergroten...

Dat kan nooit "echte" packetloss zijn, dat schreef ik juist in mijn eerdere bericht. Als je werkelijk 10% packetloss zou hebben zouden alle andere bestemmingen (die immers via je default gateway lopen) ook minimaal 10% packetloss moeten hebben en dat is niet zo blijkt uit je eerdere traceroute tests. Wat je hier ziet is dat je default gateway het blijkbaar af en toe druk heeft waardoor hij niet reageert op pings en die weggooit. Dat is normaal gedrag van een netwerk component. Maar het kan dus wel een signaal zijn dat er "iets" aan de hand is in jouw netwerk segment wat er voor zorgt dat je gateway het druk heeft.


Rogi zei:
Ziet er naar uit dat het probleem is opgelost op dit moment.
Klik om te vergroten...

Ik zou nog niet te vroeg juichen, als je probleem namelijk veroorzaakt wordt door te weinig capaciteit kan het nu misschien rustig zijn en komt het weer terug als het drukker wordt. Het kan natuurlijk ook zijn dat er een defect component was waardoor de rest 'op zijn tenen' draaide en dat dit nu gerepareerd is. Afwachten dus :wink:
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan