Zen's latency

Just wondering if anybody has experienced an increase in their latency recently. I have the line on fast path and was getting good pings but I've had an unexplained spike in latency that hasn't corrected itself.

Here's an example of the increase, while the ADSL was still connected.
http://www.thinkbroadband.com/ping/share/df629242c8f...

Previous:
2 13 ms 14 ms 13 ms losubs.subs.dsl1.mbr-roch.zen.net.uk [62.3.82.17]

Current:
2 27 ms 27 ms 29 ms losubs.subs.dsl1.mbr-roch.zen.net.uk [62.3.82.17]

This isn't the first time this has happened but it doesn't seem to be resolving itself as it did in past cases.

Here's another oddity. The pings decreased in ~10ms increments until back to normal. The first drop was caused by a reconnection to get a better gateway, although the original gateway started off at the >50ms mark and dropped down over a period of a few minutes until it hit the ~20ms mark, all without any reconnection. It seemed a little bit like (alright, exactly like) the connection profile was set on auto interleave and a burst of errors has caused it to increase the depth, although I've been told that it's not. It happened a bit too quickly to be clearly seen on the chart.

As a gamer, I value a connection with low latency and given that I use fast path, I value it over speed. However, the latency I'm receiving at the moment is worse than I'd expect to receive on your average interleaved connection.

So, my question is, has anybody else experienced similar oddities or have any possible explanation of what's going on? I really can't think of anything apart from the connection possibly being mistakenly on auto as I believe it may have been prior to my move to Zen (it'd explain a lot as the same behaviour is visible in my last ISP's monitor). I've seen the behavior of the system when a line has a burst of errors after moving to Zen when the line was set 'back' to auto. Doing anything intensive with the connection at that point triggered a ~10ms hike in latency.

Finally, it may sound like a conspiracy theory (it's not ) but this sort of thing seems to always happen at around 10am. I can produce a number of monitor graphs showing drastic shifts in latency at around 10am. Complete coincidence? Maybe, maybe not.

Sorry for the slightly incoherent post and thanks!

Edited by deleted (Fri 08-Apr-11 19:11:25)

I've had the same problem on and off over the past few weeks/month but it's gotten better over the last week or so.

Ping is fine 'till 7:30-8PM, when it used to jump from ~60 to 100+ (sometimes average of 400 near 8PM). Then after 10PM it would slowly return to normal.

Been OK for the last week or two, with occasional spikes (in the evening). I always used to have Interleaving turned on, but I presume (by looking at the graph) it must have disabled itself then re-enabled.

Here's a graph from 22 March, showing a massive spike that happened instantly after EastEnders finished (connection was hardly being used from 8PM-9PM)

http://i.imgur.com/VefXL.png


Here's where you can see the jump around the middle of week 13 (Interleaving back on?)
http://img684.imageshack.us/img684/9589/pingwanmonth...

I had the same problem around half a year ago, hike of around 10ms that didn't want to go down for quite some time. I asked support to turn interleaving off instead of Auto and my ping went back to normal. Maybe it was a coincidence I don't know.

Lately though I've not had any problems so I can't offer any advice on that sorry.

What I'm curious about, is there different levels of 'interleaving' when set to Auto or is Auto just detection of on or off, 1 and 0? The reason I ask is my sync has gone down since manually setting interleaving off yet my ping hasn't changed from when it was Auto.

I hope you don't think I'm hijacking your post I'm just curious if tech support mentioned anything like this.

As a gamer myself it's quite frustrating isn't it, especially when you just have to sit and wait it out, especially when a lot of people don't give you much sympathy on the matter

There are different interleaving depths that the auto system can set. They're in increments of ~8ms to the best of my knowledge.

Yep, it is indeed frustrating though, especially since there's a logical explanation out there somewhere. It's not some dark magic that's beyond control as some might try and have you believe.

I don't care so much about speed as I do about latency. If that weren't the case, I could be getting better value elsewhere. I've even set the router's SNR to 20dB in the hope that if there's still some sort of error correction magic going on that it'll eventually stop. We'll see but hey, it's worth a try.

In addition to that, I ensure I'm connected to one of the Manchester or Rochdale gateways as some of the others (Leeds to name one) produce some pretty horrid latency (talking 50ms first hop on 'fast path').

Thumbs up:
7 17 ms 17 ms 17 ms www1.multiplay.co.uk [85.236.96.22]

Not so much:
10 48 ms 47 ms 51 ms www.multiplay.co.uk [85.236.96.68]

The first time I made a request about this, the problem magically went away after they said they'd get on it. I'm not sure if it was luck or if they actually did something which was later undone (the line profile was changed from fast to auto and back to fast again).

Edited by deleted (Tue 12-Apr-11 06:10:56)

Interesting, thanks. I don't want to risk going back to Auto even though my ping was just as good as it is now on 'off'.

Since 21CN I've always been connected to Manchester even though I'm closer to Leeds. I don't think I've ever noticed been connected to Leeds gateway since ADSL2 for some reason.

We don't have 21cn infrastructure in Leeds, just 20cn. Being in the north you should therefore typically only connect to our Manchester gateways.

Carl

Cool, thanks for the info.

On a slightly related note, is OP or anyone getting a slow response to servers lately? Not a higher latency but a quite a delay before a server responds at all.

Pings are fine, connection seems normal, browsing normal... just pings are hanging for a good 10 seconds

Even when you ping the IP address?

Sounds like DNS.

Try using Googls DNS on the PC/MAC and test the connection, then do the same for Our DNS. Once done can you let me know the results please.

I'll get back to you on this. It could be the software causing the ping delay, seems okay from windows

I've noticed my ping has gone up to 65 from 45 on Zen over the past week.

Normal here; (London)

Pinging bbc.co.uk [212.58.224.138] with 32 bytes of data:

Reply from 212.58.224.138: bytes=32 time=7ms TTL=122
Reply from 212.58.224.138: bytes=32 time=7ms TTL=122
Reply from 212.58.224.138: bytes=32 time=7ms TTL=122
Reply from 212.58.224.138: bytes=32 time=8ms TTL=122

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

Edited by IamQ (Sun 24-Apr-11 13:39:27)

In reply to a post by IamQ:

Normal here; (London)

Pinging bbc.co.uk [212.58.224.138] with 32 bytes of data:

Reply from 212.58.224.138: bytes=32 time=7ms TTL=122
Reply from 212.58.224.138: bytes=32 time=7ms TTL=122
Reply from 212.58.224.138: bytes=32 time=7ms TTL=122
Reply from 212.58.224.138: bytes=32 time=8ms TTL=122

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

Could you post a trace please?

From the Linux box (Same end point)

[root@xs ~]# ping bbc.co.uk
PING bbc.co.uk (212.58.224.138) 56(84) bytes of data.
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=1 ttl=122 time=8.22 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=2 ttl=122 time=7.98 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=3 ttl=122 time=8.21 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=4 ttl=122 time=7.96 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=5 ttl=122 time=8.16 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=6 ttl=122 time=7.41 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=7 ttl=122 time=8.13 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=8 ttl=122 time=7.86 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=9 ttl=122 time=8.58 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=10 ttl=122 time=8.06 ms

--- bbc.co.uk ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 7.412/8.061/8.582/0.287 ms



And the route (Over ICMP);

[root@xs ~]# traceroute -I bbc.co.uk
traceroute to bbc.co.uk (212.58.224.138), 30 hops max, 40 byte packets
1 gateway-to-the-void.goth.int (172.16.0.1) 0.216 ms 0.194 ms 0.192 ms
2 losubs.subs.dsl2.th-lon.zen.net.uk (62.3.84.21) 8.031 ms 8.477 ms 7.365 ms
3 ae0-114.cr1.th-lon.zen.net.net (62.3.84.185) 8.686 ms 8.646 ms 9.194 ms
4 82.71.254.134 (82.71.254.134) 11.313 ms 11.462 ms 12.052 ms
5 212.58.238.129 (212.58.238.129) 12.510 ms 13.959 ms 14.005 ms
6 virtual-vip.thdo.bbc.co.uk (212.58.224.138) 14.343 ms 16.138 ms 16.238 ms

In reply to a post by IamQ:

From the Linux box (Same end point)

[root@xs ~]# ping bbc.co.uk
PING bbc.co.uk (212.58.224.138) 56(84) bytes of data.
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=1 ttl=122 time=8.22 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=2 ttl=122 time=7.98 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=3 ttl=122 time=8.21 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=4 ttl=122 time=7.96 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=5 ttl=122 time=8.16 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=6 ttl=122 time=7.41 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=7 ttl=122 time=8.13 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=8 ttl=122 time=7.86 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=9 ttl=122 time=8.58 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=10 ttl=122 time=8.06 ms

--- bbc.co.uk ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 7.412/8.061/8.582/0.287 ms



And the route (Over ICMP);

[root@xs ~]# traceroute -I bbc.co.uk
traceroute to bbc.co.uk (212.58.224.138), 30 hops max, 40 byte packets
1 gateway-to-the-void.goth.int (172.16.0.1) 0.216 ms 0.194 ms 0.192 ms
2 losubs.subs.dsl2.th-lon.zen.net.uk (62.3.84.21) 8.031 ms 8.477 ms 7.365 ms
3 ae0-114.cr1.th-lon.zen.net.net (62.3.84.185) 8.686 ms 8.646 ms 9.194 ms
4 82.71.254.134 (82.71.254.134) 11.313 ms 11.462 ms 12.052 ms
5 212.58.238.129 (212.58.238.129) 12.510 ms 13.959 ms 14.005 ms
6 virtual-vip.thdo.bbc.co.uk (212.58.224.138) 14.343 ms 16.138 ms 16.238 ms

Thanks. Interesting though. I wonder why can't I connect to the London gateway? :/

In reply to a post by Btcc22:

Thanks. Interesting though. I wonder why can't I connect to the London gateway? :/

It all depends where you are in the UK and which node your exchange is on. If you have a look at the zen network map it should make things a bit easier to understand the layout.

http://www.zen.co.uk/userfiles/images/shared/site/co...

Can you do a traceroute and ping to the same bbc address and post that back for us to have a look at.

Tracing route to bbc.co.uk [212.58.224.138]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.0.0.2
2 20 ms 19 ms 18 ms losubs.subs.dsl1.mbr-roch.zen.net.uk [62.3.82.17
]
3 17 ms 18 ms 19 ms ae0-136.cr1.mbr-roch.zen.net.uk [62.3.80.137]
4 19 ms 18 ms 18 ms ae2-0.cr1.kp-leeds.zen.net.uk [62.3.80.70]
5 20 ms 18 ms 19 ms ge-3-1-0-0.cr2.kp-leeds.zen.net.uk [62.3.80.74]

6 23 ms 23 ms 22 ms ge-3-0-0-0.cr1.th-lon.zen.net.uk [62.3.80.78]
7 24 ms 23 ms 23 ms 82.71.254.134
8 25 ms 24 ms 23 ms 212.58.238.153
9 24 ms 24 ms 24 ms virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Trace complete.

It connects me to the Rochdale, Leeds and Manchester gateways. I'd prefer the London ones to be added in, although it's not a huge deal. The latency as you can see has gone down quite a bit to an acceptable level since my original post, although it's still elevated in comparison to the original values.

Here's an example for Leeds gateway:
Tracing route to 95.211.120.168 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.0.0.2
2 39 ms 39 ms 41 ms losubs.subs.dsl1.kp-leeds.zen.net.uk [62.3.85.17
]
3 39 ms 39 ms 39 ms ae0-113.cr2.kp-leeds.zen.net.uk [62.3.85.181]
4 44 ms 44 ms 44 ms ge-3-0-0-0.cr1.th-lon.zen.net.uk [62.3.80.78]
5 44 ms 43 ms 43 ms ge-2-0-0-0.cr2.th-lon.zen.net.uk [62.3.80.42]
6 52 ms 51 ms 52 ms lon.tc2.leaseweb.net [195.66.225.100]
7 52 ms 52 ms 52 ms te4-3.sr10.evo.leaseweb.net [62.212.80.66]
8 52 ms 52 ms 51 ms 95.211.120.168

Trace complete.

Thanks for the link by the way. It's only around 8ms higher than optimal conditions at the moment anyway, so as said, it's not a big deal.

Edited by deleted (Sun 24-Apr-11 17:49:53)

You might be interested in this set of results then;

From another end point on the london network. - This line has interleaving switched on - without reading all the posts here I'd guess your line is also in interleaved mode going on the responce times.


[root@muffin ~]# traceroute -I bbc.co.uk
traceroute to bbc.co.uk (212.58.224.138), 30 hops max, 40 byte packets
1 gatekeeper.goth.int (172.16.10.1) 0.319 ms 0.312 ms 0.318 ms
2 losubs.subs.dsl2.th-lon.zen.net.uk (62.3.84.21) 19.052 ms 19.763 ms 20.746 ms
3 ae0-114.cr1.th-lon.zen.net.net (62.3.84.185) 21.950 ms 25.399 ms 26.368 ms
4 82.71.254.134 (82.71.254.134) 27.340 ms 28.071 ms 28.807 ms
5 212.58.238.153 (212.58.238.153) 30.265 ms 31.003 ms 31.733 ms
6 virtual-vip.thdo.bbc.co.uk (212.58.224.138) 32.705 ms 34.834 ms 35.295 ms



[root@muffin ~]# ping bbc.co.uk
PING bbc.co.uk (212.58.224.138) 56(84) bytes of data.
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=1 ttl=122 time=18.9 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=2 ttl=122 time=18.5 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=3 ttl=122 time=19.0 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=4 ttl=122 time=19.5 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=5 ttl=122 time=18.9 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=6 ttl=122 time=18.6 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=7 ttl=122 time=19.0 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=8 ttl=122 time=19.0 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=9 ttl=122 time=18.9 ms
64 bytes from virtual-vip.thdo.bbc.co.uk (212.58.224.138): icmp_seq=10 ttl=122 time=19.4 ms

--- bbc.co.uk ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9001ms
rtt min/avg/max/mdev = 18.576/19.037/19.557/0.340 ms

Nah, it's on fast path to the best of my knowledge. I'm able to force the sync up to 8128 with a low enough noise margin and as I understand it, an interleaved line can't go that high.

Edited by deleted (Sun 24-Apr-11 19:09:58)

It can...

I've had interleaved lines running by default at 8128 down so don't be tricked by that one.

Can you post your line stats and trace please.

Trace:

Tracing route to bbc.co.uk [212.58.224.138]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.0.0.2
2 18 ms 17 ms 17 ms losubs.subs.dsl1.mbr-roch.zen.net.uk [62.3.82.17
]
3 18 ms 19 ms 18 ms ae0-136.cr1.mbr-roch.zen.net.uk [62.3.80.137]
4 22 ms 21 ms 19 ms ae2-0.cr1.kp-leeds.zen.net.uk [62.3.80.70]
5 19 ms 18 ms 18 ms ge-3-1-0-0.cr2.kp-leeds.zen.net.uk [62.3.80.74]

6 24 ms 23 ms 23 ms ge-3-0-0-0.cr1.th-lon.zen.net.uk [62.3.80.78]
7 24 ms 24 ms 22 ms 82.71.254.134
8 24 ms 24 ms 24 ms 212.58.238.153
9 24 ms 24 ms 24 ms virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Trace complete.

Stats (delay was 0.25 and channel fast even when interleaving was set to auto but had a ~20ms depth):

Mode: G.DMT
Channel: Fast
Trellis: ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.4 25.0
Attn(dB): 31.0 18.0
Pwr(dBm): 19.7 11.9
Max(Kbps): 8896 1136
Rate (Kbps): 8128 448
G.dmt framing
K: 255(0) 15
R: 0 0
S: 1 1
D: 1 1
ADSL2 framing
MSGc: 1 1
B: 239 15
M: 1 1
T: 1 1
R: 0 0
S: 1.0000 1.0000
L: 1920 128
D: 1 1
Counters
SF: 25381917 25381874
SFErr: 19120 10
RS: 0 0
RSCorr: 0 0
RSUnCorr: 0 0

HEC: 12571 6
OCD: 208 0
LCD: 0 0
Total Cells: 3976611804 0
Data Cells: 158188030 0
Drop Cells: 706
Bit Errors: 0 0

ES: 5994 0
SES: 152 0
UAS: 105 0
AS: 431492

INP: 0.00 0.00
PER: 1.75 1.75
delay: 0.25 0.25
OR: 32.00 32.00

Bitswap: 0 0

Edited by deleted (Mon 25-Apr-11 14:21:10)

An update on this. Back up to a 100% increase in latency after two step increases over the past couple of days.

It's a shame that there doesn't seem to be any explanation for this other than "it happens". An interleaved connection would have better latency than Zen on fast path as it stands.

Edited by deleted (Mon 16-May-11 18:12:59)