High Ping (New Problem) Small amount of Packet Loss(Problem for a while now)

[Westy]

For the record, my ping times have finally settled back to ~7ms, and the packet loss is very sporadic. Typically 7pm-1am with peaks of 2% on 1 minute sample averages but over the entire period it is actually < 0.01% ie. negligible.

Westy, I assume you've tried a ping -n 100 192.168.1.0 from your PC to router just to ensure there aren't any spikes there. You've probably done that already, but it's always a good confidence booster to know it's not your side of the router. I presume you've reset the line by leaving it off for 30 mins/overnight/whatever. I would say something is definitely up if you get more than 100ms to idnet.net, I was always around 20ms even when interleaved, and it is sometimes in single figures.

Although it is 0.01% over the entire period is negligible, 2% during the 1 minute where i am competitively playing a game trying to win £50 is not negligible I'm afraid. I can accept the problem may not be fixable, but i refuse to accept that it is not a problem. It just seems very convenient that it starts 3 weeks after my connection is installed, and still no one can locate the problem! But right now thats not my main concern, the ping spikes are a much larger deal! I have contacted ID net support and have done all the tests they wanted me to do to confirm that the problem is not my end, so they should hopefully now be looking into the matter. Will keep this thread updated with how it all goes.

[Westy]

Can someone tell me what "Ping -n" does? A member of IDnet support asked me to do another test in safemode and the results seemed good, yet when i did a tracert in safe mode to the same IP the results looked not so good!

Code Select Expand

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Westy>ping -n 100 212.69.40.3

Pinging 212.69.40.3 with 32 bytes of data:
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=16ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=16ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=18ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61
Reply from 212.69.40.3: bytes=32 time=17ms TTL=61

Ping statistics for 212.69.40.3:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 18ms, Average = 17ms

C:\Users\Westy>tracert 212.69.40.3

Tracing route to resolver1.idnet.net [212.69.40.3]
over a maximum of 30 hops:

  1     1 ms    <1 ms     1 ms  192.168.0.1
  2    22 ms    18 ms    17 ms  telehouse-gw4-lo2.idnet.net [212.69.63.99]
  3   256 ms    39 ms    17 ms  telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]

  4    19 ms    17 ms    18 ms  telehouse-gw1-fa0-0.400.idnet.net [212.69.63.241
]
  5    20 ms    19 ms    18 ms  resolver1.idnet.net [212.69.40.3]

Trace complete.

C:\Users\Westy>

[Rik]

Ping -n simply pings for the number of times you state, eg -n 20.

[esh]

Since 212.69.40.3 is fine, but you see the spike at 212.69.63.243, did you try pinging that for a bit also? Most likely I suspect the spikes are random in nature, in which case it's the line or your router I would say. Pinging your router for a long while should get you a feel for if the spikes are coming from there.

I also agree that packet loss is a sign something is wrong, but it seems to actually be fairly standard these days, or at least becoming much more common. It certainly was not 2 years ago. Things are pushed to their limit. I know it's frustrating to know your line can be better, because I know the feeling -- mine has been slowly deteriorating, but I don't have the time or motivation to chase a lost 1.5Mbits from the ether.

Have you run something like the TBB broadband tester for 24 hours or so to see what this lag/loss looks like and if it is entirely related by time of day?

[Simon_idnet]

Since 212.69.40.3 is fine, but you see the spike at 212.69.63.243, did you try pinging that for a bit also? Most likely I suspect the spikes are random in nature, in which case it's the line or your router I would say. Pinging your router for a long while should get you a feel for if the spikes are coming from there.

212.69.63.243 is a Cisco router and will treat any ICMP Echo packets ("pings") addressed to it directly (includes traceroutes) as low priority and as such will show random "high pings" which should not be confused with 'network issues'. The litmus test is to ping a host on the other side of that router - if the router were the bottleneck then pings to the far host would be incrementally higher than pinging the router directly, which is not the case.

I also agree that packet loss is a sign something is wrong, but it seems to actually be fairly standard these days, or at least becoming much more common. It certainly was not 2 years ago. Things are pushed to their limit. I know it's frustrating to know your line can be better, because I know the feeling -- mine has been slowly deteriorating, but I don't have the time or motivation to chase a lost 1.5Mbits from the ether.

Have you run something like the TBB broadband tester for 24 hours or so to see what this lag/loss looks like and if it is entirely related by time of day?

Cross-talk is becoming more of an issue over the past year or so. Where more and more neighbours are becoming enabled for high-speed ADSL more phone lines are emitting interference and so when they meet in the underground ducts to travel back to the exchange they are interfering with each other!
Simon

[Rik]

Presumably, that can only get worse, Simon, even with vDSL?

[Glenn]

3.37, was that a late night or early morning?

[esh]

212.69.63.243 is a Cisco router and will treat any ICMP Echo packets ("pings") addressed to it directly (includes traceroutes) as low priority and as such will show random "high pings" which should not be confused with 'network issues'.

That's good to know, but I would still expect it wouldn't show *that* many high spikes (unless there was an issue with the line). All of us get the odd peak. About 3-4 times a day I get a brief 1 minute period where the gateway has in excess of 2,000 ms ping.


Out of interest, is the cross-talk different with the newer technologies that use different frequencies, do you have any feel for that?

[Simon_idnet]

Presumably, that can only get worse, Simon, even with vDSL?

Fibre is, or course, immune from electrical interference and the VDSL bit is on a much shorter copper run and less likely to travel parallel to other lines but when they do then the higher power and higher frequencies will create cross-talk.

[Rik]

Great, a new set of problems to learn about.

[Simon_idnet]

That's good to know, but I would still expect it wouldn't show *that* many high spikes (unless there was an issue with the line). All of us get the odd peak. About 3-4 times a day I get a brief 1 minute period where the gateway has in excess of 2,000 ms ping.

It's irrelevant as you're not measureing traffic passing through the router only pings aimed at it.

Out of interest, is the cross-talk different with the newer technologies that use different frequencies, do you have any feel for that?

It is more of a problem on ADSL2+ as that uses almost twice the range of frequencies which doubles the scope for interference.

[esh]

Interesting, since ADSL2 has just been enabled in this area. I wonder if it really is cross-talk in my case.

I think I follow your argument re: the router. You are implying that without knowledge of the quantity of traffic passing through the router you cannot really infer the specific source of latency since the ICMP is of low priority. Unless I'm confused. It makes sense, I just somewhat crudely assume routers aren't generally loaded enough to cause frequent huge ping spikes, but then I only deal with (comparatively) small networks...

[Lance]

Its just saying that if the router happens to receive the ping request at the same time as another request, the other request will be serviced first. I assume that other request could be as simple as passing a packet through.

[esh]

Absolutely. It's just that unless the traffic volume is very high you'd still imagine you'd get serviced quite fast. But of course, without knowledge of the traffic at the time, one couldn't really disentangle your local ping variations from the remote ones.

[Westy]

Well i have just been told that my internet is fine, due to that one normal ping test I did. Yet every other single test (Done is safe mode with me being the only computer on the network) clearly shows massive ping spikes...

[Rik]

Remind me, Westy, you are on a wired connection aren't you?

[Westy]

Remind me, Westy, you are on a wired connection aren't you?

Yes, as you may have notice i take concern about the quality of my connection, and with gaming a wireless connection is just awful!

[Rik]

Just removing one more variable from the equation. I really don't know what else to suggest, clearly, IDNet can't see a fault and a ping to a router is always prone to spiking because of the way they respond to ICMP traffic. Did you allow ICMP on your own router so that they could test the connection to you?

[Westy]

Just removing one more variable from the equation. I really don't know what else to suggest, clearly, IDNet can't see a fault and a ping to a router is always prone to spiking because of the way they respond to ICMP traffic. Did you allow ICMP on your own router so that they could test the connection to you?

I am afraid all this ICMP stuff is where i started to be out of my depth! Could you explain it a little please?

[sof2er]

Basically by default (I think) you can't ping an IP behind a router unless you've enabled it.

I know netgear routers have an option under "Wan Setup" called Respond to Ping on Internet Port, make sure it's ticked if you've got Netgear (or search for something similiar if it's a different brand router).

[Rik]

In your router setup, there will be an option to allow the router to respond to ICMP traffic, ie pings. For security, I disable it (which means my router can't easily be seen by malevolent script kiddies). However, if it's on, it allows IDNet to ping your router and see what results they get, ie whether there are any spikes from their end.

What router are you using (apologies if you said, somewhere, but it's been a long day).

[Westy]

In your router setup, there will be an option to allow the router to respond to ICMP traffic, ie pings. For security, I disable it (which means my router can't easily be seen by malevolent script kiddies). However, if it's on, it allows IDNet to ping your router and see what results they get, ie whether there are any spikes from their end.

What router are you using (apologies if you said, somewhere, but it's been a long day).

Netgear DG834G

[Rik]

What sof2er said then. Once it's enabled, let support know and they run some tests.

[Westy]

What sof2er said then. Once it's enabled, let support know and they run some tests.

Well i enabled it and let them know on thursday, have yet to have a reply, so its another weekend not being able to play any of my games!

[Rik]

They'll test for at least 24 hours before getting back to you.