Higher than expected average latency/jitter

[Zensunni]

Hello all,

I'm a relatively new IDNet customer who wanted to get away from the cheap ISP packages that sell 'unlimited' broadband packages with limits and block/manage customer network traffic. So I'm quite happy with IDNet policy, but am experiencing some issues with actual performance.

I'm an off-again/on-again MMORPG player, so when I'm in a playing mode, latency becomes especially important to me. I wasn't playing anything at the time of my move to IDNet, so I didn't really pay any attention to my latency when I first switched, and just ran a few quick speed tests over the first week with speedtest.net. The up and download rates were good, though the ping rate usually seemed a bit high (usually 30-40ms, whereas before I had always had 20-25ms), but I didn't think too much of it.

I've since started playing AoC and noticed some issues with latency, and the game would often be reporting a ping of 60-90ms at various times (previous experience with other MMOs tended to show latency around 30ms). I decided to run some pings yesterday. I ran a traceroute to a website and noted the first ip address I hit outside my router and rang a ping test to that. I was surprised to see quite a few spikes. I thought I'd try again today after a router reboot, and am still seeing spikes.

I called IDNet support, and the gent initially suggested turning off interleaving, but I pointed out that my pings often show around 10-15ms and only occasionally spike higher for a few packets, though the spikes bring the average for this test up to 38ms. (We decided to go ahead with turning off interleaving, which will take up to 24 hours, to see if it helps). He felt a device on my network must be sending out spurts of traffic, but I was monitoring the pc's network traffic during this ping test and incoming/outgoing traffic during the test maxed at 1.1Kbs. No other kit attached to my router was on at the time of the test, my pc for the test is wired to the router, the WAN interface of my router is MAC-restricted and no other devices were reported as being attached to the router.

To follow is the traceroute and ping test, followed by router statistics and then a BT speedtest. I'm really keen on sticking with IDNet for the reasons I mentioned at the beginning, but consistent jitter would be a deal-breaker for me. Any advice is appreciated.

*******************************************************
   TRACEROUTE AND PING TEST
*******************************************************
Last login: Thu May 29 18:23:55 on console
computername:~ username$ traceroute google.co.uk
traceroute: Warning: google.co.uk has multiple addresses; using 72.14.221.104
traceroute to google.co.uk (72.14.221.104), 64 hops max, 40 byte packets
1  192.168.0.1 (192.168.0.1)  1.306 ms  0.634 ms  3.052 ms
2  telehouse-gw2-lo1.idnet.net (212.69.63.51)  13.535 ms  12.674 ms  15.467 ms
3  telehouse-gw3-g0-1-400.idnet.net (212.69.63.243)  13.580 ms  11.404 ms  12.048 ms
4  195.66.224.125 (195.66.224.125)  12.611 ms  14.173 ms  28.828 ms
5  209.85.252.42 (209.85.252.42)  20.703 ms  29.439 ms  32.003 ms
6  209.85.252.4 (209.85.252.4)  40.280 ms  29.490 ms  35.644 ms
7  72.14.232.165 (72.14.232.165)  33.746 ms  32.638 ms  27.762 ms
8  72.14.232.190 (72.14.232.190)  48.321 ms 209.85.250.42 (209.85.250.42)  38.676 ms 72.14.232.190 (72.14.232.190)  39.553 ms
9  fg-in-f104.google.com (72.14.221.104)  28.405 ms  30.843 ms  28.356 ms
computername:~ username$ ping 212.69.63.51
PING 212.69.63.51 (212.69.63.51): 56 data bytes
64 bytes from 212.69.63.51: icmp_seq=0 ttl=254 time=11.803 ms
64 bytes from 212.69.63.51: icmp_seq=1 ttl=254 time=15.674 ms
64 bytes from 212.69.63.51: icmp_seq=2 ttl=254 time=15.337 ms
64 bytes from 212.69.63.51: icmp_seq=3 ttl=254 time=10.582 ms
64 bytes from 212.69.63.51: icmp_seq=4 ttl=254 time=12.241 ms
64 bytes from 212.69.63.51: icmp_seq=5 ttl=254 time=13.141 ms
64 bytes from 212.69.63.51: icmp_seq=6 ttl=254 time=11.827 ms
64 bytes from 212.69.63.51: icmp_seq=7 ttl=254 time=11.761 ms
64 bytes from 212.69.63.51: icmp_seq=8 ttl=254 time=20.052 ms
64 bytes from 212.69.63.51: icmp_seq=9 ttl=254 time=12.099 ms
64 bytes from 212.69.63.51: icmp_seq=10 ttl=254 time=12.260 ms
64 bytes from 212.69.63.51: icmp_seq=11 ttl=254 time=15.142 ms
64 bytes from 212.69.63.51: icmp_seq=12 ttl=254 time=80.870 ms
64 bytes from 212.69.63.51: icmp_seq=13 ttl=254 time=12.275 ms
64 bytes from 212.69.63.51: icmp_seq=14 ttl=254 time=10.978 ms
64 bytes from 212.69.63.51: icmp_seq=15 ttl=254 time=10.905 ms
64 bytes from 212.69.63.51: icmp_seq=16 ttl=254 time=11.826 ms
64 bytes from 212.69.63.51: icmp_seq=17 ttl=254 time=11.741 ms
64 bytes from 212.69.63.51: icmp_seq=18 ttl=254 time=12.914 ms
64 bytes from 212.69.63.51: icmp_seq=19 ttl=254 time=13.603 ms
64 bytes from 212.69.63.51: icmp_seq=20 ttl=254 time=12.532 ms
64 bytes from 212.69.63.51: icmp_seq=21 ttl=254 time=10.483 ms
64 bytes from 212.69.63.51: icmp_seq=22 ttl=254 time=11.381 ms
64 bytes from 212.69.63.51: icmp_seq=23 ttl=254 time=11.309 ms
64 bytes from 212.69.63.51: icmp_seq=24 ttl=254 time=10.732 ms
64 bytes from 212.69.63.51: icmp_seq=25 ttl=254 time=12.662 ms
64 bytes from 212.69.63.51: icmp_seq=26 ttl=254 time=13.774 ms
64 bytes from 212.69.63.51: icmp_seq=27 ttl=254 time=12.714 ms
64 bytes from 212.69.63.51: icmp_seq=28 ttl=254 time=10.648 ms
64 bytes from 212.69.63.51: icmp_seq=29 ttl=254 time=16.737 ms
64 bytes from 212.69.63.51: icmp_seq=30 ttl=254 time=11.707 ms
64 bytes from 212.69.63.51: icmp_seq=31 ttl=254 time=12.139 ms
64 bytes from 212.69.63.51: icmp_seq=32 ttl=254 time=36.224 ms
64 bytes from 212.69.63.51: icmp_seq=33 ttl=254 time=11.984 ms
64 bytes from 212.69.63.51: icmp_seq=34 ttl=254 time=11.675 ms
64 bytes from 212.69.63.51: icmp_seq=35 ttl=254 time=17.760 ms
64 bytes from 212.69.63.51: icmp_seq=36 ttl=254 time=10.755 ms
64 bytes from 212.69.63.51: icmp_seq=37 ttl=254 time=16.861 ms
64 bytes from 212.69.63.51: icmp_seq=38 ttl=254 time=12.814 ms
64 bytes from 212.69.63.51: icmp_seq=39 ttl=254 time=10.771 ms
64 bytes from 212.69.63.51: icmp_seq=40 ttl=254 time=12.414 ms
64 bytes from 212.69.63.51: icmp_seq=41 ttl=254 time=19.503 ms
64 bytes from 212.69.63.51: icmp_seq=42 ttl=254 time=14.988 ms
64 bytes from 212.69.63.51: icmp_seq=43 ttl=254 time=11.940 ms
64 bytes from 212.69.63.51: icmp_seq=44 ttl=254 time=10.382 ms
64 bytes from 212.69.63.51: icmp_seq=45 ttl=254 time=12.047 ms
64 bytes from 212.69.63.51: icmp_seq=46 ttl=254 time=10.975 ms
64 bytes from 212.69.63.51: icmp_seq=47 ttl=254 time=14.361 ms
64 bytes from 212.69.63.51: icmp_seq=48 ttl=254 time=10.836 ms
64 bytes from 212.69.63.51: icmp_seq=49 ttl=254 time=11.984 ms
64 bytes from 212.69.63.51: icmp_seq=50 ttl=254 time=11.181 ms
64 bytes from 212.69.63.51: icmp_seq=51 ttl=254 time=12.628 ms
64 bytes from 212.69.63.51: icmp_seq=52 ttl=254 time=18.468 ms
64 bytes from 212.69.63.51: icmp_seq=53 ttl=254 time=631.073 ms
64 bytes from 212.69.63.51: icmp_seq=54 ttl=254 time=375.847 ms
64 bytes from 212.69.63.51: icmp_seq=55 ttl=254 time=11.657 ms
64 bytes from 212.69.63.51: icmp_seq=56 ttl=254 time=11.322 ms
64 bytes from 212.69.63.51: icmp_seq=57 ttl=254 time=12.014 ms
64 bytes from 212.69.63.51: icmp_seq=58 ttl=254 time=12.178 ms
64 bytes from 212.69.63.51: icmp_seq=59 ttl=254 time=12.362 ms
64 bytes from 212.69.63.51: icmp_seq=60 ttl=254 time=15.234 ms
64 bytes from 212.69.63.51: icmp_seq=61 ttl=254 time=13.190 ms
64 bytes from 212.69.63.51: icmp_seq=62 ttl=254 time=11.412 ms
64 bytes from 212.69.63.51: icmp_seq=63 ttl=254 time=11.336 ms
64 bytes from 212.69.63.51: icmp_seq=64 ttl=254 time=13.461 ms
64 bytes from 212.69.63.51: icmp_seq=65 ttl=254 time=10.915 ms
64 bytes from 212.69.63.51: icmp_seq=66 ttl=254 time=11.336 ms
64 bytes from 212.69.63.51: icmp_seq=67 ttl=254 time=11.517 ms
64 bytes from 212.69.63.51: icmp_seq=68 ttl=254 time=26.701 ms
64 bytes from 212.69.63.51: icmp_seq=69 ttl=254 time=11.113 ms
64 bytes from 212.69.63.51: icmp_seq=70 ttl=254 time=12.495 ms
64 bytes from 212.69.63.51: icmp_seq=71 ttl=254 time=11.952 ms
64 bytes from 212.69.63.51: icmp_seq=72 ttl=254 time=104.091 ms
64 bytes from 212.69.63.51: icmp_seq=73 ttl=254 time=11.291 ms
64 bytes from 212.69.63.51: icmp_seq=74 ttl=254 time=17.623 ms
64 bytes from 212.69.63.51: icmp_seq=75 ttl=254 time=30.146 ms
64 bytes from 212.69.63.51: icmp_seq=76 ttl=254 time=10.829 ms
64 bytes from 212.69.63.51: icmp_seq=77 ttl=254 time=11.247 ms
64 bytes from 212.69.63.51: icmp_seq=78 ttl=254 time=19.061 ms
64 bytes from 212.69.63.51: icmp_seq=79 ttl=254 time=11.825 ms
64 bytes from 212.69.63.51: icmp_seq=80 ttl=254 time=15.464 ms
64 bytes from 212.69.63.51: icmp_seq=81 ttl=254 time=12.439 ms
64 bytes from 212.69.63.51: icmp_seq=82 ttl=254 time=11.140 ms
64 bytes from 212.69.63.51: icmp_seq=83 ttl=254 time=19.190 ms
64 bytes from 212.69.63.51: icmp_seq=84 ttl=254 time=13.673 ms
64 bytes from 212.69.63.51: icmp_seq=85 ttl=254 time=11.134 ms
64 bytes from 212.69.63.51: icmp_seq=86 ttl=254 time=11.786 ms
64 bytes from 212.69.63.51: icmp_seq=87 ttl=254 time=11.500 ms
64 bytes from 212.69.63.51: icmp_seq=88 ttl=254 time=17.318 ms
64 bytes from 212.69.63.51: icmp_seq=89 ttl=254 time=18.494 ms
64 bytes from 212.69.63.51: icmp_seq=90 ttl=254 time=12.240 ms
64 bytes from 212.69.63.51: icmp_seq=91 ttl=254 time=12.182 ms
64 bytes from 212.69.63.51: icmp_seq=92 ttl=254 time=15.294 ms
64 bytes from 212.69.63.51: icmp_seq=93 ttl=254 time=10.787 ms
64 bytes from 212.69.63.51: icmp_seq=94 ttl=254 time=10.442 ms
64 bytes from 212.69.63.51: icmp_seq=95 ttl=254 time=11.365 ms
64 bytes from 212.69.63.51: icmp_seq=96 ttl=254 time=13.990 ms
64 bytes from 212.69.63.51: icmp_seq=97 ttl=254 time=107.666 ms
64 bytes from 212.69.63.51: icmp_seq=98 ttl=254 time=74.744 ms
64 bytes from 212.69.63.51: icmp_seq=99 ttl=254 time=67.000 ms
64 bytes from 212.69.63.51: icmp_seq=100 ttl=254 time=62.993 ms
64 bytes from 212.69.63.51: icmp_seq=101 ttl=254 time=94.212 ms
64 bytes from 212.69.63.51: icmp_seq=102 ttl=254 time=73.220 ms
64 bytes from 212.69.63.51: icmp_seq=103 ttl=254 time=103.790 ms
64 bytes from 212.69.63.51: icmp_seq=104 ttl=254 time=75.067 ms
64 bytes from 212.69.63.51: icmp_seq=105 ttl=254 time=71.566 ms
64 bytes from 212.69.63.51: icmp_seq=106 ttl=254 time=93.656 ms
64 bytes from 212.69.63.51: icmp_seq=107 ttl=254 time=77.791 ms
64 bytes from 212.69.63.51: icmp_seq=108 ttl=254 time=68.355 ms
64 bytes from 212.69.63.51: icmp_seq=109 ttl=254 time=73.445 ms
64 bytes from 212.69.63.51: icmp_seq=110 ttl=254 time=77.548 ms
64 bytes from 212.69.63.51: icmp_seq=111 ttl=254 time=72.296 ms
64 bytes from 212.69.63.51: icmp_seq=112 ttl=254 time=77.623 ms
64 bytes from 212.69.63.51: icmp_seq=113 ttl=254 time=646.962 ms
64 bytes from 212.69.63.51: icmp_seq=114 ttl=254 time=331.807 ms
64 bytes from 212.69.63.51: icmp_seq=115 ttl=254 time=11.891 ms
64 bytes from 212.69.63.51: icmp_seq=116 ttl=254 time=11.334 ms
64 bytes from 212.69.63.51: icmp_seq=117 ttl=254 time=17.435 ms
64 bytes from 212.69.63.51: icmp_seq=118 ttl=254 time=12.906 ms
64 bytes from 212.69.63.51: icmp_seq=119 ttl=254 time=35.542 ms
64 bytes from 212.69.63.51: icmp_seq=120 ttl=254 time=11.315 ms
64 bytes from 212.69.63.51: icmp_seq=121 ttl=254 time=11.502 ms
64 bytes from 212.69.63.51: icmp_seq=122 ttl=254 time=11.410 ms
64 bytes from 212.69.63.51: icmp_seq=123 ttl=254 time=21.206 ms
64 bytes from 212.69.63.51: icmp_seq=124 ttl=254 time=13.722 ms
64 bytes from 212.69.63.51: icmp_seq=125 ttl=254 time=12.933 ms
64 bytes from 212.69.63.51: icmp_seq=126 ttl=254 time=11.357 ms
64 bytes from 212.69.63.51: icmp_seq=127 ttl=254 time=13.494 ms
64 bytes from 212.69.63.51: icmp_seq=128 ttl=254 time=12.429 ms
^C
--- 212.69.63.51 ping statistics ---
129 packets transmitted, 129 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.382/38.018/646.962/89.128 ms
computername:~ username$


*******************************************************
   ROUTER STATISTICS
*******************************************************
   
System Up Time 00:32:04
Port    Status    TxPkts    RxPkts    Collisions    Tx B/s    Rx B/s    Up Time
WAN    PPPoA    2942    3893    0    285    1704    00:31:17
LAN    10M/100M    2287    2082    0    1057    187    00:32:00
WLAN    11M/54M    2028    1354    0    723    168    00:31:52

ADSL Link    Downstream    Upstream
Connection Speed    8128 kbps    448 kbps
Line Attenuation    33 db    11 db
Noise Margin    9 db    22 db

*******************************************************
   BT SPEEDTEST
*******************************************************

Test1 comprises of Best Effort Test:  -provides background information.
    IP profile for your line is - 7150 kbps
    DSL connection rate: 448 kbps(UP-STREAM)  8128 kbps(DOWN-STREAM)
    Actual IP throughput achieved during the test was - 6048 kbps

[Rik]

Hi, welcome to the forum.

Before I forget it, I'd just mention that I don't regard MAC addresses as a good form of security, they are easy to spoof.

I'm guessing you are on GW5 (your login will end thus if you are)? We've had people report that dropping the PPP session and re-connecting has cured this problem for them. I'm not sure if you can, though, with a Netgear, so you might need to try forcing a re-sync instead.

Download a copy of Ping Graph and run that for an extended period, eg several hours up to 24 hours. Set it to graph 5ms above your average to the site, ie if it's 15, set the Y axis to 20ms, then set it to log anything over 20ms.

See if that shows up a pattern. We have been noticing a variety of line problems since February, when BT did some network upgrades, and there is ongoing work in connection with 21CN and WBC which BT don't seem to be admitting to.

[Zensunni]

Hi, welcome to the forum.

Wow, thx for the *speedy* reply!

Before I forget it, I'd just mention that I don't regard MAC addresses as a good form of security, they are easy to spoof.

<best Andy impression>Yeah, I know.</> I'd like to set it up for WPA2, but my silly Windows Mobile 5 phone doesn't support it. WEP is pretty worthless, and even WPA isn't ideal. But you're right, I should at least add WPA.

I'm guessing you are on GW5 (your login will end thus if you are)? We've had people report that dropping the PPP session and re-connecting has cured this problem for them. I'm not sure if you can, though, with a Netgear, so you might need to try forcing a re-sync instead.

Yes to the first question.

I'm guessing then that rebooting doesn't drop the PPP session, which I've already done? The modem does allow me to 'disconnect' from the 'show connection' window. I did that, waited for it to fully disconnect, then reconnected. Is that resetting the PPP session? If so, I'll do some more monitoring to see if it helped. If not, can you direct me to instructions on how to force a re-sync?

Download a copy of Ping Graph and run that for an extended period, eg several hours up to 24 hours. Set it to graph 5ms above your average to the site, ie if it's 15, set the Y axis to 20ms, then set it to log anything over 20ms.

See if that shows up a pattern. We have been noticing a variety of line problems since February, when BT did some network upgrades, and there is ongoing work in connection with 21CN and WBC which BT don't seem to be admitting to.

Thanks for the info. I'll try that out if resetting the PPP session didn't/doesn't help. Fingers crossed that it's not a BT misconfiguration/change!

[Zensunni]

The modem does allow me to 'disconnect' from the 'show connection' window. I did that, waited for it to fully disconnect, then reconnected.

I'm afraid this doesn't seem to have helped--hopefully there's something else to do to reset the PPP session!

The ping test I just ran is now much worse than the earlier one; it's actually much closer to what I was seeing yesterday evening. I ran the earlier test a little more than an hour ago, so am guessing this is more of a timing thing than the disconnect/reconnect causing it to jump. Here's the most recent ping. Again, I monitored the net traffic from my pc during this test; outgoing/incoming maxed at about 300 Bs during the test (sorry, I should have noted the earlier figure as 1.1 KBs, not 1.1Kbs).

Please do let me know if there's something else I need to do to resync.

Cheers.

-----

computername:~ username$ ping 212.69.63.51
PING 212.69.63.51 (212.69.63.51): 56 data bytes
64 bytes from 212.69.63.51: icmp_seq=0 ttl=254 time=42.963 ms
64 bytes from 212.69.63.51: icmp_seq=1 ttl=254 time=38.357 ms
64 bytes from 212.69.63.51: icmp_seq=2 ttl=254 time=26.469 ms
64 bytes from 212.69.63.51: icmp_seq=3 ttl=254 time=160.961 ms
64 bytes from 212.69.63.51: icmp_seq=4 ttl=254 time=28.044 ms
64 bytes from 212.69.63.51: icmp_seq=5 ttl=254 time=32.682 ms
64 bytes from 212.69.63.51: icmp_seq=6 ttl=254 time=44.464 ms
64 bytes from 212.69.63.51: icmp_seq=7 ttl=254 time=34.002 ms
64 bytes from 212.69.63.51: icmp_seq=8 ttl=254 time=44.571 ms
64 bytes from 212.69.63.51: icmp_seq=9 ttl=254 time=30.379 ms
64 bytes from 212.69.63.51: icmp_seq=10 ttl=254 time=41.715 ms
64 bytes from 212.69.63.51: icmp_seq=11 ttl=254 time=34.941 ms
64 bytes from 212.69.63.51: icmp_seq=12 ttl=254 time=40.058 ms
64 bytes from 212.69.63.51: icmp_seq=13 ttl=254 time=149.965 ms
64 bytes from 212.69.63.51: icmp_seq=14 ttl=254 time=41.703 ms
64 bytes from 212.69.63.51: icmp_seq=15 ttl=254 time=36.874 ms
64 bytes from 212.69.63.51: icmp_seq=16 ttl=254 time=35.837 ms
64 bytes from 212.69.63.51: icmp_seq=17 ttl=254 time=37.982 ms
64 bytes from 212.69.63.51: icmp_seq=18 ttl=254 time=25.328 ms
64 bytes from 212.69.63.51: icmp_seq=19 ttl=254 time=42.306 ms
64 bytes from 212.69.63.51: icmp_seq=20 ttl=254 time=35.517 ms
64 bytes from 212.69.63.51: icmp_seq=21 ttl=254 time=44.142 ms
64 bytes from 212.69.63.51: icmp_seq=22 ttl=254 time=37.826 ms
64 bytes from 212.69.63.51: icmp_seq=23 ttl=254 time=34.799 ms
64 bytes from 212.69.63.51: icmp_seq=24 ttl=254 time=33.986 ms
64 bytes from 212.69.63.51: icmp_seq=25 ttl=254 time=43.347 ms
64 bytes from 212.69.63.51: icmp_seq=26 ttl=254 time=40.572 ms
64 bytes from 212.69.63.51: icmp_seq=27 ttl=254 time=44.443 ms
64 bytes from 212.69.63.51: icmp_seq=28 ttl=254 time=44.385 ms
64 bytes from 212.69.63.51: icmp_seq=29 ttl=254 time=30.434 ms
64 bytes from 212.69.63.51: icmp_seq=30 ttl=254 time=30.104 ms
64 bytes from 212.69.63.51: icmp_seq=31 ttl=254 time=39.982 ms
64 bytes from 212.69.63.51: icmp_seq=32 ttl=254 time=88.180 ms
64 bytes from 212.69.63.51: icmp_seq=33 ttl=254 time=36.299 ms
64 bytes from 212.69.63.51: icmp_seq=34 ttl=254 time=46.638 ms
64 bytes from 212.69.63.51: icmp_seq=35 ttl=254 time=22.860 ms
64 bytes from 212.69.63.51: icmp_seq=36 ttl=254 time=37.550 ms
64 bytes from 212.69.63.51: icmp_seq=37 ttl=254 time=40.502 ms
64 bytes from 212.69.63.51: icmp_seq=38 ttl=254 time=44.358 ms
64 bytes from 212.69.63.51: icmp_seq=39 ttl=254 time=39.617 ms
64 bytes from 212.69.63.51: icmp_seq=40 ttl=254 time=28.149 ms
64 bytes from 212.69.63.51: icmp_seq=41 ttl=254 time=43.893 ms
64 bytes from 212.69.63.51: icmp_seq=42 ttl=254 time=13.680 ms
64 bytes from 212.69.63.51: icmp_seq=43 ttl=254 time=27.427 ms
64 bytes from 212.69.63.51: icmp_seq=44 ttl=254 time=30.073 ms
64 bytes from 212.69.63.51: icmp_seq=45 ttl=254 time=43.349 ms
64 bytes from 212.69.63.51: icmp_seq=46 ttl=254 time=38.826 ms
64 bytes from 212.69.63.51: icmp_seq=47 ttl=254 time=42.721 ms
64 bytes from 212.69.63.51: icmp_seq=48 ttl=254 time=36.680 ms
64 bytes from 212.69.63.51: icmp_seq=49 ttl=254 time=32.376 ms
64 bytes from 212.69.63.51: icmp_seq=50 ttl=254 time=43.691 ms
64 bytes from 212.69.63.51: icmp_seq=51 ttl=254 time=672.594 ms
64 bytes from 212.69.63.51: icmp_seq=52 ttl=254 time=56.890 ms
64 bytes from 212.69.63.51: icmp_seq=53 ttl=254 time=53.891 ms
64 bytes from 212.69.63.51: icmp_seq=54 ttl=254 time=71.812 ms
64 bytes from 212.69.63.51: icmp_seq=55 ttl=254 time=63.384 ms
64 bytes from 212.69.63.51: icmp_seq=56 ttl=254 time=73.178 ms
64 bytes from 212.69.63.51: icmp_seq=57 ttl=254 time=64.257 ms
64 bytes from 212.69.63.51: icmp_seq=59 ttl=254 time=81.352 ms
64 bytes from 212.69.63.51: icmp_seq=60 ttl=254 time=80.520 ms
64 bytes from 212.69.63.51: icmp_seq=61 ttl=254 time=85.616 ms
64 bytes from 212.69.63.51: icmp_seq=62 ttl=254 time=80.361 ms
64 bytes from 212.69.63.51: icmp_seq=63 ttl=254 time=615.451 ms
64 bytes from 212.69.63.51: icmp_seq=64 ttl=254 time=125.561 ms
64 bytes from 212.69.63.51: icmp_seq=65 ttl=254 time=42.222 ms
64 bytes from 212.69.63.51: icmp_seq=66 ttl=254 time=30.008 ms
64 bytes from 212.69.63.51: icmp_seq=67 ttl=254 time=44.296 ms
64 bytes from 212.69.63.51: icmp_seq=68 ttl=254 time=41.977 ms
64 bytes from 212.69.63.51: icmp_seq=69 ttl=254 time=45.104 ms
64 bytes from 212.69.63.51: icmp_seq=70 ttl=254 time=42.564 ms
64 bytes from 212.69.63.51: icmp_seq=73 ttl=254 time=37.914 ms
64 bytes from 212.69.63.51: icmp_seq=74 ttl=254 time=38.821 ms
64 bytes from 212.69.63.51: icmp_seq=75 ttl=254 time=44.677 ms
^C
--- 212.69.63.51 ping statistics ---
76 packets transmitted, 73 packets received, 3% packet loss
round-trip min/avg/max/stddev = 13.680/63.814/672.594/100.685 ms

[Sebby]

You're not the first person to report this. Take a look here and here, for example.

Unfortunately, it's currently looking like the problem is external to IDNet, though if the problem is clear, IDNet may be able to change their routing.

As you've tried restarting the PPP session, I'd suggest you send an email to support with some tracerts, and perhaps point them to this thread. It's necessary they're made aware of the problem, and given as much data as possible, in order to find the cause and put a fix in place.

I hope this helps.

[Nova]

You're not the first person to report this. Take a look here and here, for example.

Unfortunately, it's currently looking like the problem is external to IDNet, though if the problem is clear, IDNet may be able to change their routing.

As you've tried restarting the PPP session, I'd suggest you send an email to support with some tracerts, and perhaps point them to this thread. It's necessary they're made aware of the problem, and given as much data as possible, in order to find the cause and put a fix in place.

I hope this helps.

I'm no longer certain it's OUTSIDE IDnet's network, it looks like it's a specific router acting funny during peak times : 212.69.63.55 <--- That one is the one I am having issues with, and it seems that it's the first "hop" on this one too, which puts it firmly inside IDnet's domain.

Nova

[Simon]

I'm no longer certain it's OUTSIDE IDnet's network, it looks like it's a specific router acting funny during peak times : 212.69.63.55 <--- That one is the one I am having issues with, and it seems that it's the first "hop" on this one too, which puts it firmly inside IDnet's domain.

Nova

Hi Nova,

If you think you've nailed it down to a specific, then the best (only) course of action is to contact IDNet with the details, as only they can investigate that for you.  Useful to have the info here though. 

[Lance]

I think it is important to remember that the idnet servers give pings a very low priority. This will be why there is spikes in the ping tests, especially on the first hop in the idnet network.

[Zensunni]

Thanks for the links, guys. I saw the WoW one earlier, but thought it might not apply to my issue since the consensus seemed to be that the issue was outside IDnet.

I ran PingGraph overnight and continued to see fairly regular spikes. It was only set to log once every 10s, so I wouldn't be surprised if there were even more spikes, since the instances don't usually last 10s.

I'll rerun tonight with polls at 5s and also run a log of net activity to/from the pc, which I forgot to do overnight, to rule-out self-generated traffic.

I think it is important to remember that the idnet servers give pings a very low priority. This will be why there is spikes in the ping tests, especially on the first hop in the idnet network.

Hmm... Well, can you direct me to an ip address of an IDNet server that does respond well to pings? I'd really like to rule out whether this is internal (BT caused or otherwise) or external to your network, and simply pinging google.co.uk or another UK website isn't really going to help determine that.

I am a bit disappointed that the tech guy didn't say that, to be honest. He went through at least three attempts to say that the high ping was being caused by me: 1) my pc generating the traffic (I pointed out that I was monitoring my net traffic as in my first post) 2) my unprotected WAN (sure, MACs can be spoofed, but nevertheless they'd show as being attached to the router, and only my PC was listed as such) and 3) my pc had a virus or some malware (I run up-to-date anti-virus on my Windoze pc and my Mac, well, just doesn't have the need--*yet*, I know). He never indicated it could be that IDNet servers don't treat pings with a high priority and that could be causing the spikes.

If you're unable to provide an ip address of an internal server to ping, I suppose I could carry on with the server I've been doing and pinging a UK server concurrently to see if the spikes tend to occur at the same time.

[Dangerjunkie]

Hi Zen,

I think it is important to remember that the idnet servers give pings a very low priority. This will be why there is spikes in the ping tests, especially on the first hop in the idnet network.

I work with large networks and I can confirm what Lance says. Over a satellite-delivered system I will often get a set of pings like:

1: Lost
2: Lost
3: 1800ms
4: 670ms
5: 680ms

When a serious router gets congested and needs to drop something it will tend to be intelligent about what gets sent to the great bit-bucket in the sky. Dropping ICMP pings is an easy thing to do and will have no direct consequence (other than to the ping stats). TCP is reliable and dropping a TCP packet will cause a NAK (Negative AcKnowledgment - "Message not received correctly") to be sent back and the original data to be resent which will make the problem worse by generating even more traffic and may cause an impact on the application by creating a spike in delay times.

The use of pings is not always a good test for these reasons. If your application has a delay measurement mechanism in its stats that may give you a more real answer. Also it's worth remembering that these drops quite likely don't happen in IDNet's network but somewhere else along the way.

Cheers,
Paul.

[Lance]

Zen,

I'm not sure if any of the IDNet servers are configured to treat pings with a higher priority. I would imagine that concurrent pinging might be the way forward. I suggest the BBC as it seems to give consistent results.

Thanks
Lance

[Rik]

Hi Zen

Try pinging the forum:

ping 212.69.36.28

Pinging 212.69.36.28 with 32 bytes of data:

Reply from 212.69.36.28: bytes=32 time=28ms TTL=59
Reply from 212.69.36.28: bytes=32 time=23ms TTL=59
Reply from 212.69.36.28: bytes=32 time=24ms TTL=59
Reply from 212.69.36.28: bytes=32 time=24ms TTL=59

Ping statistics for 212.69.36.28:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 28ms, Average = 24ms

(My line is interleaved).

[Nova]

Hi Zen,



I work with large networks and I can confirm what Lance says. Over a satellite-delivered system I will often get a set of pings like:

1: Lost
2: Lost
3: 1800ms
4: 670ms
5: 680ms

When a serious router gets congested and needs to drop something it will tend to be intelligent about what gets sent to the great bit-bucket in the sky. Dropping ICMP pings is an easy thing to do and will have no direct consequence (other than to the ping stats). TCP is reliable and dropping a TCP packet will cause a NAK (Negative AcKnowledgment - "Message not received correctly") to be sent back and the original data to be resent which will make the problem worse by generating even more traffic and may cause an impact on the application by creating a spike in delay times.

The use of pings is not always a good test for these reasons. If your application has a delay measurement mechanism in its stats that may give you a more real answer. Also it's worth remembering that these drops quite likely don't happen in IDNet's network but somewhere else along the way.

Cheers,
Paul.

This might be true but if the router is congested and thus dropping packets this would instantly explain why several people have started reporting this, if we're losing packets which need to be resent, this creates the spikes people would be seeing, and the "jitter" effect several of us are reporting. If so this may be a case of isolating the "overloaded node" on the network and giving it a stern talking to.

Nova

[Lance]

It might not be that the router is congested, but rather it just has something better it could be doing first.

[Nova]

It might not be that the router is congested, but rather it just has something better it could be doing first.

If at the same time the pings happen, gamers can reliably report that they are seeing similar "jitter" in their games, I would call that congestion or something very much untoward with the connection, given this is now starting to crop up from multiple people and over different games, this is starting to hint that the problem has come up inside the last 3 weeks and it is -internal- to IDNET's network.

I would find it a bit surprising that the techs would attempt to disregard that as a potential answer if the reports start showing up from multiple sources.

Nova

[Rik]

One of the problems they face is that BT are continuing to do work for WBC/21CN and that ISPs are not being advised of it specifically.

[Nova]

One of the problems they face is that BT are continuing to do work for WBC/21CN and that ISPs are not being advised of it specifically.

God bless british telecom... 

Nova

[Rik]

And we do, frequently.

[Nova]

And we do, frequently.

In their faces if we could...

Nova

[Wingco1]

Ping plotter


[attachment deleted by admin]

[Rik]

If you can let support have the graphs and logs, that will help them track the cause.