Hey there, been with IDnet for a while and need some help with a few problems.
Firstly, I bought a new PC 2 days ago and installed windows 7. A few hours after i had got it up and running IDNet goes down, and ever since i have been having ping spikes from 30-150. Now i have done a tracert and it seems fairly obvious that the problem is the internet and not the computer, but if theres any other ways to check i will.
If it definitely is the internet, then has anyone else been experiencing the same thing? And knows why or when it will be sorted?
Secondly, i have been having a big problem with packet loss for a long time. (Only 1-6% packet loss, but it really makes a different when gaming), It started when i was originally with BT. It only happens during peak hours, and is perfectly fine between ofpeak hours (by peak i mean specifically 5 and 12). So after numerous talks with BT they said the problem was either my end (When i had constantly proved it wasn't) Or that up to 25% packet loss is normal (Which is isn't). So at which point i moved to IDNet. For the first month it was fine, no loss or anything. Then after that first month the loss came back again. I contacted IDNet about it once but nothing ended up happening about it. I will contact them directly again but i was just curious as to what people on here had to say about it.
Thanks
:welc: :karma:
Can't help with the tech stuff, sorry, but someone will be along soon. :)
Since the recent outage my connection has returned to its normal behaviour with low pings and no packet loss which suggests to me that the issue is peculiar to your connection and has been present for sometime. It would be easy to blame local exchange congestion especially since it occurs at peak times.I would collect a series of BT speedtests and evidence of packet loss and send them to support.
:welc: :karma:
:welc: :karma:
Quote from: Westy on Oct 21, 2010, 23:09:00
Secondly, i have been having a big problem with packet loss for a long time. (Only 1-6% packet loss, but it really makes a different when gaming), It started when i was originally with BT. It only happens during peak hours, and is perfectly fine between ofpeak hours (by peak i mean specifically 5 and 12). So after numerous talks with BT they said the problem was either my end (When i had constantly proved it wasn't) Or that up to 25% packet loss is normal (Which is isn't). So at which point i moved to IDNet. For the first month it was fine, no loss or anything. Then after that first month the loss came back again. I contacted IDNet about it once but nothing ended up happening about it. I will contact them directly again but i was just curious as to what people on here had to say about it.
Thanks
I've been getting the same since the new bandwidth allowance came in.
For example :
(http://www.thinkbroadband.com/ping/share-thumb/1c8fa587c2c1f68193c28c8056d74a45-11-10-2010.png) (http://www.thinkbroadband.com/ping/share/1c8fa587c2c1f68193c28c8056d74a45-11-10-2010.html)
(http://www.thinkbroadband.com/ping/share-thumb/24f1f0cf2bc7ab66690c38b8798b44ed-14-10-2010.png) (http://www.thinkbroadband.com/ping/share/24f1f0cf2bc7ab66690c38b8798b44ed-14-10-2010.html)
(http://www.thinkbroadband.com/ping/share-thumb/168d96794fbf3c748082dbbd4ce15cb3-21-10-2010.png) (http://www.thinkbroadband.com/ping/share/168d96794fbf3c748082dbbd4ce15cb3-21-10-2010.html)
I have contacted IDnet about the packet loss and the response I got back wasn't that great to be honest.
In what way, Paul? Your graphs seem to be indicating the packet loss starts at midnight, when most ISPs switch to off-peak rates and all the big downloads start. That's bound to produce some congestion if the exchange isn't lightly loaded in the first place.
It also happens in the evenings between 7pm - 11pm, its only 1% - 5% but that does cause problems playing games or streaming stuff.
Remember my justin.tv streaming problems? it only happens when the monitor shows packet loss. I can no longer watch iPlayer between midnight and 2am now when I used to use the offpeak time to catch up on programs missed, it constantly buffers / stutters all the time.
On some occasions I have started suffering packet loss at peak times also, but I haven't seen it for about a week now so I am monitoring that. My ping is still on average 3x higher than it was before the incident, though it is still quite low. Perhaps I am on a different VP or something, I don't know.
Quote from: psp83 on Oct 22, 2010, 10:59:26
Remember my justin.tv streaming problems? it only happens when the monitor shows packet loss. I can no longer watch iPlayer between midnight and 2am now when I used to use the offpeak time to catch up on programs missed, it constantly buffers / stutters all the time.
All of which suggests exchange congestion. What did support say?
Quote from: esh on Oct 22, 2010, 11:03:08
On some occasions I have started suffering packet loss at peak times also, but I haven't seen it for about a week now so I am monitoring that. My ping is still on average 3x higher than it was before the incident, though it is still quite low. Perhaps I am on a different VP or something, I don't know.
Do two or three BT speedtests, add in a tracert to www.idnet.net and let support have the results, esh. Nothing which happened over the past couple of weeks should affect ping times, unless there's a local issue.
Quote from: Rik on Oct 22, 2010, 11:12:03
All of which suggests exchange congestion. What did support say?
My speed and tracerts are all normal thou.. speed always around 4.6mb on a 5000 profile and tracerts always come back under 20ms. Its just the packet loss is the issue.
Support didn't comment on packet loss in the evening just on the issue after midnight.
QuoteHi Paul
Midnight is when many ISPs switch to the "off-peak" download tariff which seems to cause a surge in download activity which causes congestion.
Regards
Simon
Thats all was said and to be honest is no used to me, I would just like to be able to use my connection when I want to, not have to stay up to certain times to use it.
LLU?
Quote from: Rik on Oct 22, 2010, 11:13:35
Do two or three BT speedtests, add in a tracert to www.idnet.net and let support have the results, esh. Nothing which happened over the past couple of weeks should affect ping times, unless there's a local issue.
I've done all that, followed all the steps given by Brian and basically get no where even when I do give links to my tbb monitor showing increased ping times and packet loss.
I've got nothing againts IDnet, I like them. I just want my old connection back where I didn't have to worry on the time of day when to use certain part of the net.
Quote from: Rik on Oct 22, 2010, 13:01:45
LLU?
I would but there's only cheap nasty ones on our exchange.
| AOL: | Enabled |
| O2 / Be: | Not available |
| C&W / Bulldog: | Not available |
| Edge Telecom: | Not available |
| Entanet: | Not available |
| Lumison: | Not available |
| NewNet: | Not available |
| Node4: | Not available |
| Orange: | Enabled as of 17/12/2007 |
| Pipex: | Not available |
| Sky / Easynet: | Enabled as of 27/03/2007 |
| Smallworld: | Not available |
| TalkTalk (CPW): | Enabled |
| Tiscali: | Enabled as of 01/05/2008 |
| Tiscali TV: | Enabled as of 01/05/2008 |
| WB Internet: | Not available |
| Zen Internet: | Not available |
@Westy, when your ping problem starts could you post your tracert to the server, your pathping to the server. Make sure you're using a wired connection and disconnect all other devices, it's possible that some other device might be interfering.
(tracert 1.2.3.4 and pathping 1.2.3.4 -q 25)
@paul
I've had a very good ping and no packet loss after previous weeks major outage but after wednesday's outage my ping has increased by 3-4 ms and I'm getting constant packetloss throughout the day.
(http://www.thinkbroadband.com/ping/share-thumb/ff1d69732d1703271905554d06a9f90f.png) (http://www.thinkbroadband.com/ping/share/ff1d69732d1703271905554d06a9f90f.html)
We've had a topic before on packet loss and it's sure it has something to do with peak times and off peak as all the packetloss graphs were similiar indicating nothing to do with exchange congestion.
Quote from: sof2er on Oct 22, 2010, 13:33:54
We've had a topic before on packet loss and it's sure it has something to do with peak times and off peak as all the packetloss graphs were similiar indicating nothing to do with exchange congestion.
My ping has also increased from 13 ms to 18ms but I've been seeing the packet loss for alot longer.
I know its not my end causing the packet loss & I'm refusing to spend money on yet another router, I've bought 2 already this year and get the same with both connected.
And as you say and looking at other IDnet customer tbb monitors, the packet loss is nearly the same on every one. But I don't seem to be getting anywhere when reporting this issue.
Even when I was with Tiscali I never saw constant packet loss on them, only when there was network issues.
C:\Users\Westy>tracert www.bbc.co.uk
Tracing route to www.bbc.net.uk [212.58.244.71]
over a maximum of 30 hops:
1 <1 ms 1 ms 1 ms 192.168.0.1
2 33 ms 32 ms 34 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 34 ms 33 ms 32 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
4 34 ms 33 ms 32 ms rt-lonap-a.thdo.bbc.co.uk [193.203.5.90]
5 32 ms 31 ms 33 ms 212.58.238.129
6 42 ms 52 ms 52 ms 212.58.239.58
7 38 ms 43 ms 61 ms 212.58.251.44
8 34 ms 33 ms 33 ms bbc-vip116.telhc.bbc.co.uk [212.58.244.71]
Trace complete.
That one is just a small spike, but it does go up to 100+ sometimes
Heres a better one
C:\Users\Westy>tracert www.bbc.co.uk
Tracing route to www.bbc.net.uk [212.58.246.90]
over a maximum of 30 hops:
1 <1 ms <1 ms 1 ms 192.168.0.1
2 55 ms 46 ms 39 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 45 ms 54 ms 46 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
4 51 ms 68 ms 66 ms rt-lonap-a.thdo.bbc.co.uk [193.203.5.90]
5 59 ms 70 ms 80 ms 212.58.238.129
6 68 ms 84 ms 104 ms te12-1.hsw0.cwwtf.bbc.co.uk [212.58.239.222]
7 104 ms 118 ms 110 ms 212.58.255.12
8 79 ms 85 ms 90 ms bbc-vip011.cwwtf.bbc.co.uk [212.58.246.90]
Trace complete.
That could just be the BBC routers being busy, Westy. Try a tracert to www.idnet.net.
Didn't Simon, a while back, suggest running ping tests to the secondary DNS server?
Or that. ;D
Quote from: Rik on Oct 23, 2010, 10:40:21
That could just be the BBC routers being busy, Westy. Try a tracert to www.idnet.net.
C:\Users\Westy>tracert www.idnet.net
Tracing route to www.idnet.net [212.69.36.10]
over a maximum of 30 hops:
1 <1 ms 1 ms 1 ms 192.168.0.1
2 32 ms 32 ms 32 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 35 ms 64 ms 37 ms telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]
4 35 ms 33 ms 33 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
5 40 ms 35 ms 50 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
6 78 ms 42 ms 36 ms redbus-gw1-fa2-0-300.idnet.net [212.69.63.225]
7 35 ms 63 ms 111 ms www.idnet.net [212.69.36.10]
Trace complete.
By comparison:
tracert www.idnet.net
Tracing route to www.idnet.net [212.69.36.10]
over a maximum of 30 hops:
1 2 ms <1 ms 1 ms 192.168.1.254
2 15 ms 13 ms 14 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 14 ms 13 ms 13 ms telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]
4 14 ms 11 ms 13 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
5 14 ms 13 ms 13 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
6 16 ms 15 ms 14 ms redbus-gw1-fa2-0-300.idnet.net [212.69.63.225]
7 13 ms 13 ms 13 ms www.idnet.net [212.69.36.10]
Trace complete.
Is your line interleaved do you know? One thing I can say is that the routers give ICMP traffic a low priority, so you may just have been unlucky. Try another two or three traces at different times of the day and let support have the results, they can then test your line (make sure your router responds to ICMP traffic).
Quote from: Rik on Oct 23, 2010, 20:09:51
By comparison:
tracert www.idnet.net
Tracing route to www.idnet.net [212.69.36.10]
over a maximum of 30 hops:
1 2 ms <1 ms 1 ms 192.168.1.254
2 15 ms 13 ms 14 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 14 ms 13 ms 13 ms telehouse-gw3-g0-1-400.idnet.net [212.69.63.243]
4 14 ms 11 ms 13 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
5 14 ms 13 ms 13 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
6 16 ms 15 ms 14 ms redbus-gw1-fa2-0-300.idnet.net [212.69.63.225]
7 13 ms 13 ms 13 ms www.idnet.net [212.69.36.10]
Trace complete.
Is your line interleaved do you know? One thing I can say is that the routers give ICMP traffic a low priority, so you may just have been unlucky. Try another two or three traces at different times of the day and let support have the results, they can then test your line (make sure your router responds to ICMP traffic).
I have interleaving turned off. And the high pings spikes has been constant for the last 3/4 days, yet no problem before the downtime.
How often did you test? As I say, let support have a few traces and they'll check your line - provided your router responds to ICMP. Have you any background tasks running?
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.
Quote from: esh on Oct 26, 2010, 12:22:43
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.
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!
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>
Ping -n simply pings for the number of times you state, eg -n 20.
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?
Quote from: esh on Oct 26, 2010, 22:31:04
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.
Quote
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
Presumably, that can only get worse, Simon, even with vDSL?
3.37, was that a late night or early morning?
Quote from: Simon_idnet on Oct 27, 2010, 03:37:48
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?
Quote from: Rik on Oct 27, 2010, 08:30:26
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.
Great, a new set of problems to learn about. ;)
Quote from: esh on Oct 27, 2010, 09:04:01
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.
Quote
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.
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...
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.
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.
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...
Remind me, Westy, you are on a wired connection aren't you?
Quote from: Rik on Oct 27, 2010, 18:15:29
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!
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?
Quote from: Rik on Oct 27, 2010, 18:25:55
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?
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).
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).
Quote from: Rik on Oct 27, 2010, 19:09:24
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
What sof2er said then. :) Once it's enabled, let support know and they run some tests.
Quote from: Rik on Oct 28, 2010, 08:20:28
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!
They'll test for at least 24 hours before getting back to you.