[WXC/VFX] >10 second ping times, 33% packet loss over ADSL

Forums › One NZ (including Farmside) › [WXC/VFX] >10 second ping times, 33% packet loss over ADSL

aw

296 posts

Ultimate Geek
+1 received by user: 30

#76201 30-Jan-2011 10:41

Hi all,

I'm needing a little help trying to figure out a fault with my ADSL.

Throughput is shockingly unreliable, as shown by ping times at the bottom of the post. This has been going on since Thursday and is the same with either a Dynalink RTA1025W or a Belkin F6D4630-4 v1.

It's the same whether pinging from my home server (openSUSE 11.1) which connects to the router over wired Ethernet with a gigabit switch inbetween, or over my Windows XP laptop connected to either modem's own wireless (except that pings from Windows time out after 5 seconds).

This is a cabinetised ADSL2+ connection in Mt Albert, Auckland.

Xnet havd a monitor the line for the past 24 hours and have found nothing wrong.

I don't have easy access to someone else's ADSL line to try these modems on another line as suggested by Xnet, but two modems experiencing the same fault would be just odd.

I have a backup wireless connection - via Woosh - and that was working fine until this morning, now it won't authenticate (router reports PPP auth times out), but that's a separate issue. Currently I'm working through my mobile phone as a modem, but that's one PC only.

Anyone got any ideas?

(this is the last few dozen lines of ping output, plexy.wxnz.net is www.xnet.co.nz)
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=159 ttl=59 time=7.39 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=160 ttl=59 time=7.61 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=161 ttl=59 time=7.60 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=162 ttl=59 time=73.8 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=163 ttl=59 time=330 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=164 ttl=59 time=1226 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=165 ttl=59 time=1714 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=166 ttl=59 time=1150 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=167 ttl=59 time=826 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=168 ttl=59 time=284 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=169 ttl=59 time=311 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=170 ttl=59 time=7.37 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=171 ttl=59 time=6.97 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=172 ttl=59 time=685 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=173 ttl=59 time=503 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=174 ttl=59 time=1019 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=175 ttl=59 time=460 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=178 ttl=59 time=120 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=179 ttl=59 time=7.00 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=183 ttl=59 time=470 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=184 ttl=59 time=7.40 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=185 ttl=59 time=781 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=186 ttl=59 time=1821 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=187 ttl=59 time=890 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=188 ttl=59 time=2389 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=189 ttl=59 time=1660 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=190 ttl=59 time=770 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=191 ttl=59 time=3471 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=192 ttl=59 time=3524 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=193 ttl=59 time=4108 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=194 ttl=59 time=5037 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=195 ttl=59 time=5562 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=196 ttl=59 time=5701 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=197 ttl=59 time=5533 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=198 ttl=59 time=5596 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=199 ttl=59 time=5555 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=200 ttl=59 time=5419 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=201 ttl=59 time=5315 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=202 ttl=59 time=5331 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=203 ttl=59 time=5530 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=204 ttl=59 time=5679 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=205 ttl=59 time=6606 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=206 ttl=59 time=6915 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=207 ttl=59 time=7265 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=208 ttl=59 time=7263 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=209 ttl=59 time=7468 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=210 ttl=59 time=7236 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=211 ttl=59 time=7379 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=212 ttl=59 time=7267 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=213 ttl=59 time=7352 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=214 ttl=59 time=7515 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=215 ttl=59 time=7343 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=216 ttl=59 time=7812 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=217 ttl=59 time=9334 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=218 ttl=59 time=9544 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=219 ttl=59 time=9642 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=220 ttl=59 time=10369 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=221 ttl=59 time=10393 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=222 ttl=59 time=10701 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=223 ttl=59 time=11142 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=224 ttl=59 time=11742 ms
^C
--- www.xnet.co.nz ping statistics ---
329 packets transmitted, 218 received, 33% packet loss, time 329693ms
rtt min/avg/max/mdev = 6.978/3393.827/11742.798/3927.043 ms, pipe 12

rattewisday

205 posts

Master Geek
+1 received by user: 5

#432767 30-Jan-2011 10:51

Based on those results your ISP will be able to submit a fault with Telecom Wholesale - they'll probably need a few traceroutes and speed tests to support it though as Telecom are a bit funny with speed type complaints sometimes.

First step is always to do an isolation test - unplug everything except your DSL modem and then trying again. Are you on naked DSL or have you got POTS on the line? Also beware of DSL splitters (assuming you don't have a master filter installed?)..I would try the isolation test without a splitter as well just to make sure it isn't cutting off the bottom half of your signal. Is your DSL modem plugged into the master jackpoint? If you do the isolation test with and without the filter with the modem plugged into the master jack that pretty much rules out anything internal at your place (which you would be charged for if a tech was sent out). I think it is safe to assume both modems don't have the exact same fault.

EDIT: Is this a new issue or has this always been the case on the line? IMO it sounds like a line fault which will need to go through to Telecom Wholesale/Chorus. Xnet should also have the power to do a port refresh (assuming you're on a standard port profile) - there is a slight chance this would help but generally it won't do any good on a case like this. Only takes a minute to do though so see if they're willing to do that.

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#432772 30-Jan-2011 11:03

What are your ADSL modem's stats?

aw

296 posts

Ultimate Geek
+1 received by user: 30

#432791 30-Jan-2011 11:40

Forgot to mention - Xnet did do a port refresh. Ping times seemed to cone right for a minute or two only.

Yes it's a new issue - I've enjoyed a reliable 12Mbps until this happened on Thursday evening - which rules out Wilma as the cause too as that came a day later.

No other equipment added to or removed from the line.

For testing, the modem is now connected directly to the line - all other phones and all filters removed. No change.

Playing around with it, the delays seem to be relating to the load placed on it. Pinging www.xnet.co.nz from my server while (unsuccessfully) refreshing a couple of web pages on my laptop, I got the below output. I'm not making that up - 40 second ping times! I'm surprised packets get held for that long.

The 40-second pings come through sort-of steadily, as if there's some sort of holding queue. When the ping times go down, replies seem to be coming in at greater than one per second, sometimes 5 or 6 ping replies come back at once.

64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=675 ttl=59 time=45682 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=676 ttl=59 time=44801 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=677 ttl=59 time=44999 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=678 ttl=59 time=44657 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=679 ttl=59 time=43793 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=680 ttl=59 time=43743 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=681 ttl=59 time=42835 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=682 ttl=59 time=42451 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=683 ttl=59 time=42104 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=684 ttl=59 time=41592 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=685 ttl=59 time=41191 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=686 ttl=59 time=41172 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=687 ttl=59 time=40750 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=688 ttl=59 time=40288 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=689 ttl=59 time=39805 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=690 ttl=59 time=39108 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=691 ttl=59 time=39228 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=692 ttl=59 time=38745 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=693 ttl=59 time=38013 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=694 ttl=59 time=37745 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=695 ttl=59 time=37460 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=696 ttl=59 time=37272 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=697 ttl=59 time=36513 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=698 ttl=59 time=36627 ms
64 bytes from plexy.wxnz.net (58.28.6.142): icmp_seq=699 ttl=59 time=35848 ms
^C
--- www.xnet.co.nz ping statistics ---
734 packets transmitted, 433 received, 41% packet loss, time 736828ms
rtt min/avg/max/mdev = 6.627/9744.348/47169.533/12483.330 ms, pipe 47

... eventually with no other throughput, ping times will wind back down to being 7-15 milliseconds. Any traffic, and it goes up to whole or tens of seconds again.

Tests repeated with only my laptop connected on the LAN side. Same thing continues.

I've also switched back from the Belkin modem to the Dynalink. Same thing continues.

aw

296 posts

Ultimate Geek
+1 received by user: 30

#432792 30-Jan-2011 11:43

ADSL line stats, as reported by the Dynalink modem:

Current ADSL line status is displayed as the below. This is about two minutes after reconnecting the Dynalink modem.

Line Mode
ADSL2+
Line State
Show Time

Line Power State
L0
Line Up Time
00:00:02:05

Line Coding
Trellis On
Line Up Count
1

Statistics
Downstream
Upstream

Line Rate
15236 Kbps
1012 Kbps

Attainable Line Rate
18412 Kbps
1012 Kbps

Noise Margin
12.1 dB
12.8 dB

Line Attenuation
13.0 dB
5.7 dB

Output Power
18.8 dBm
12.4 dBm

MSGC (number of bytes in overhead channel message)
114
17

B (number of bytes in Mux Data Frame)
254
30

M (number of Mux Data Frames in FEC Data Frame)
1
1

T (Mux Data Frames over sync bytes)
1
3

R (number of check bytes in FEC Data Frame)
0
0

S (ratio of FEC over PMD Data Frame length)
0.5335
0.9688

L (number of bits in PMD Data Frame)
3824
256

D (interleave depth)
1
1

Delay
0
0

Super Frames
7833
7831

Super Frame Errors
0
3154

RS Words
0
0

RS Correctable Errors
0
0

RS Uncorrectable Errors
0
0

HEC Errors
0
26828

OCD Errors
0
0

LCD Errors
0
0

Total Cells
4493213
2446333813

Data Cells
6138
2164327556

Bit Errors
0
2668531

Total ES
0
0

Total SES
0
0

Total UAS
30
0

The Belkin connects at around 8Mbps and its web UI doesn't provide nearly as much statistical info.

edit: tidied up the list a bit, the table got stripped.

aw

296 posts

Ultimate Geek
+1 received by user: 30

#432793 30-Jan-2011 11:47

Hm, looking at my own stats those error rates seem pretty high. Any ideas what they could indicate?

edit: Also tested with heavy LAN traffic - no difference, ping times good when no other throughput to/from the internet, bad when there is, regardless of LAN traffic (copying an ISO from server to laptop)

rattewisday

205 posts

Master Geek
+1 received by user: 5

#432794 30-Jan-2011 11:47

Your line attenuation looks good and noise margin is decent as well. Only thing that pops out there is the 2668531 upstream bit errors which looks very high, considering you probably just swapped the modems so it would have reset to zero recently.. definately get XNet to escalate to Wholesale faults.. there is nothing you can really do on your end at this point. XNet themselves also wont have many other capabilities aside from doing line tests and port refreshes.

Lego

Shop now for Lego sets and other gifts (affiliate link).

rattewisday

205 posts

Master Geek
+1 received by user: 5

#432795 30-Jan-2011 11:53

Could you try running a traceroute to xnet.co.nz just to confirm the packet loss is actually happening between your router (should be the 1st hop) and the 2nd hop? Otherwise it is an issue in the XNet network itself (although this is probably very unlikely).

aw

296 posts

Ultimate Geek
+1 received by user: 30

#432797 30-Jan-2011 12:02

Ok, this is really embarrassing.

It was my data cap. Somehow I've managed to blow 30GB. I've turned it up and now I'm off to work out how that happened.

Thanks for your help guys and sorry to waste your time.

On a completely different note, we lost our hot water around the same time!

rattewisday

205 posts

Master Geek
+1 received by user: 5

#432806 30-Jan-2011 12:39

Happens to the best of us! Would have hopefully figured it out pretty soon anyway as the traceroutes would have shown the issue was in XNet's network.

kyhwana2

2572 posts

Uber Geek
+1 received by user: 233

#432815 30-Jan-2011 13:54

Hmm, still it's pretty sad that after you hit your data cap, your 'net connection becomes worse than dialup, latency wise.

RunningMan

9184 posts

Uber Geek
+1 received by user: 4833

#432998 31-Jan-2011 00:47

The packet loss is interesting. I've just hit my data cap, and get the following.

64 bytes from 58.28.6.142: icmp_seq=261 ttl=58 time=36.095 ms
64 bytes from 58.28.6.142: icmp_seq=262 ttl=58 time=35.350 ms
64 bytes from 58.28.6.142: icmp_seq=263 ttl=58 time=36.008 ms
64 bytes from 58.28.6.142: icmp_seq=264 ttl=58 time=36.084 ms
64 bytes from 58.28.6.142: icmp_seq=265 ttl=58 time=36.672 ms

Running a speed test at the same time to load up the connection gives a very high latency, but still no packet loss

64 bytes from 58.28.6.142: icmp_seq=154 ttl=58 time=29692.287 ms
64 bytes from 58.28.6.142: icmp_seq=155 ttl=58 time=28712.331 ms
64 bytes from 58.28.6.142: icmp_seq=156 ttl=58 time=27721.696 ms
64 bytes from 58.28.6.142: icmp_seq=157 ttl=58 time=26742.119 ms
64 bytes from 58.28.6.142: icmp_seq=158 ttl=58 time=25751.541 ms
64 bytes from 58.28.6.142: icmp_seq=159 ttl=58 time=24771.431 ms
64 bytes from 58.28.6.142: icmp_seq=160 ttl=58 time=23781.938 ms

HP

Shop now for HP laptops and other devices (affiliate link).

Niel

3267 posts

Uber Geek
+1 received by user: 80

Trusted

#433031 31-Jan-2011 08:33

The packet loss might be a pre-existing condition. Dynalink is a good performing modem, but unreliable long term. I've seen network packet loss (not ADSL) after running for 5 minutes and a few minutes later networking stops.

Your Belkin is probably only ADSL1 which is why it gets stuck at 8Mbps.

You can never have enough Volvos!

BlakJak

1329 posts

Uber Geek
+1 received by user: 735

Trusted

#433069 31-Jan-2011 10:23

RunningMan: The packet loss is interesting. I've just hit my data cap, and get the following.

64 bytes from 58.28.6.142: icmp_seq=261 ttl=58 time=36.095 ms
64 bytes from 58.28.6.142: icmp_seq=262 ttl=58 time=35.350 ms
64 bytes from 58.28.6.142: icmp_seq=263 ttl=58 time=36.008 ms
64 bytes from 58.28.6.142: icmp_seq=264 ttl=58 time=36.084 ms
64 bytes from 58.28.6.142: icmp_seq=265 ttl=58 time=36.672 ms

Running a speed test at the same time to load up the connection gives a very high latency, but still no packet loss

64 bytes from 58.28.6.142: icmp_seq=154 ttl=58 time=29692.287 ms
64 bytes from 58.28.6.142: icmp_seq=155 ttl=58 time=28712.331 ms
64 bytes from 58.28.6.142: icmp_seq=156 ttl=58 time=27721.696 ms
64 bytes from 58.28.6.142: icmp_seq=157 ttl=58 time=26742.119 ms
64 bytes from 58.28.6.142: icmp_seq=158 ttl=58 time=25751.541 ms
64 bytes from 58.28.6.142: icmp_seq=159 ttl=58 time=24771.431 ms
64 bytes from 58.28.6.142: icmp_seq=160 ttl=58 time=23781.938 ms

When I had Xnet DSL this was exactly the behavior I experienced when I hit my monthly limit and got rate-shaped to 64k. Unfortunately latencies like that make any attempt to use more than 64k/sec fail, rather than get appropriately sawtoothed via TCP.

At the time I logged a fault and Xnet told me they'd fixed it. Unfortunately for other reasons I changed ISP's, so never got to first-hand prove they'd addressed it. I guess not.

No signature to see here, move along...