Interleaving on ADSL2+

JamesAllen · Nov 04, 2010, 15:19:16

Hi guys,

While at Plusnet - my old ISP - I requested that interleaving was turned off to improve latency. This was done and seemed to be fine with ping going down below or around 30ms.

My question is, now that I've moved over to IDNet and ADSL2+, is interleaving still a factor. If so, would the interleaving still be turned off?

Looking at my ping, to a good host I get around 18 or 19ms so that would infer it is off (if still applicable to ADSL2+).

I only ask because I am doing some online streaming today - simple 128kbs which is pretty low bandwidth and I'm getting quite a few issues with the software being unable to send data fast enough which is causing pauses in the transmission.

I have at least 100k/sec of upstream as that is consistently reported via the speed tests so there shouldn't be an issue.

While I did see this kind of issue sometimes on my old ISP, I never saw them as bad as they are today.

I have a continuous ping going to my shoutcast server and on the whole it's showing a 32ms latency but that is jumping to 130ms or there abouts every so often (although when I get the issues it tends to show a normal 32ms ping) - it also shows the odd time out.

I am therefore wondering if interleaving being off (if it is) could be causing these stability issues?

My router stats seem to show a solid connection so I'm unsure where the problem lies - any ideas?

ADSL Link
Connection Speed
Line Attenuation
Noise Margin

Downstream
14363 kbps
25.0 db
5.8 db

Upstream
1159 kbps
11.1 db
6.1 db

Rik · Nov 04, 2010, 15:23:05

Boot into safe mode with network support, James, then hit Start > Run > CMD <return>. In that window, type ping www.idnet.net -n 100 and post back the summary from that will you?

JamesAllen · Nov 04, 2010, 15:32:42

Quote from: Rik on Nov 04, 2010, 15:23:05
Boot into safe mode with network support, James, then hit Start > Run > CMD <return>. In that window, type ping www.idnet.net -n 100 and post back the summary from that will you?

Hi Rik,

I can't boot into safe mode on this machine as I'm broadcasting but I ran the ping test anyway:

Pinging www.idnet.net [212.69.36.10] with 32 bytes of data:
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=18ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=36ms TTL=59
Reply from 212.69.36.10: bytes=32 time=34ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=20ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=18ms TTL=59
Reply from 212.69.36.10: bytes=32 time=21ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=20ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=21ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=21ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=27ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=37ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=20ms TTL=59
Reply from 212.69.36.10: bytes=32 time=52ms TTL=59
Reply from 212.69.36.10: bytes=32 time=96ms TTL=59
Reply from 212.69.36.10: bytes=32 time=49ms TTL=59
Reply from 212.69.36.10: bytes=32 time=90ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=20ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=19ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=23ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=18ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=18ms TTL=59
Reply from 212.69.36.10: bytes=32 time=20ms TTL=59
Reply from 212.69.36.10: bytes=32 time=24ms TTL=59
Reply from 212.69.36.10: bytes=32 time=29ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=20ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=17ms TTL=59
Reply from 212.69.36.10: bytes=32 time=16ms TTL=59

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

I can boot into safe mode on my laptop though and do this again if necessary, although the laptop is on wifi whereas this machine is wired.

Thanks for your help.

Getting quite a few problems now. Seeing ping time outs and some 150ms pings. Never had it to this level before on plusnet so something certainly isn't right somewhere.

Rik · Nov 04, 2010, 15:38:40

If you're broadcasting (uploading), your ping times will be affected, James. I'm pretty sure you're not interleaved from those figures, but let me ask some questions.

JamesAllen · Nov 04, 2010, 15:41:38

Quote from: Rik on Nov 04, 2010, 15:38:40
If you're broadcasting (uploading), your ping times will be affected, James. I'm pretty sure you're not interleaved from those figures, but let me ask some questions.

Thanks Rik.

Ah so interleaving is still part of ADSL2+? It's done at the exchange as well isn't it so I'm assuming my previous status of interleaving being off has been retained with the move to IDNet?

I did have some of these problems before on Plusnet but they weren't very often. Today I've been getting a lot which is strange. Though I imagine that being a different technology maybe interleaving being off issues may be worse - if that is the problem here. I realise there are other things to test of course.

JamesAllen · Nov 04, 2010, 15:50:56

Hi Rik,

Not sure if this helps but I just had an instance where the stream was buffering (hanging) and I was doing a trace route at the same time:

Tracing route to 213.5.180.116 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.0.3
2 211 ms 165 ms 19 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 24 ms 21 ms 17 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
4 199 ms 119 ms 25 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
5 52 ms 27 ms 41 ms ae-1.asd9nqp1.nl.ip.tdc.net [195.69.144.104]
6 116 ms 52 ms 45 ms xe-4-0-0.ldn4nqp1.uk.ip.tdc.net [83.88.29.21]
7 42 ms 44 ms 43 ms cpe.ge3-10.0xc3d76d8a.ldn2nxc7.customer.tele.dk
[195.215.109.138]
8 49 ms 31 ms 44 ms no-rdns-yet.ohtele.com [89.238.140.113]
9 52 ms * 33 ms 213.5.180.116

Trace complete.

It hook at 8, then suddenly completed and the stream was ok (both upload and download).

I notice some >100ms latency through IDNet - does this look normal to you?

Just to add another trace route - during another time out / buffering moment:

Tracing route to 213.5.180.116 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.0.3
2 21 ms 19 ms 28 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 17 ms 15 ms 19 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
4 24 ms 21 ms 19 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
5 27 ms 28 ms 36 ms ae-1.asd9nqp1.nl.ip.tdc.net [195.69.144.104]
6 30 ms 32 ms 29 ms xe-4-0-0.ldn4nqp1.uk.ip.tdc.net [83.88.29.21]
7 25 ms 28 ms 26 ms cpe.ge3-10.0xc3d76d8a.ldn2nxc7.customer.tele.dk
[195.215.109.138]
8 45 ms 192 ms 228 ms no-rdns-yet.ohtele.com [89.238.140.113]
9 69 ms 70 ms * 213.5.180.116
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 44 ms 37 ms 31 ms 213.5.180.116

Trace complete.

It is kind of looking like the issue is with the connection at the server doesn't it.. although I have only seen this since moving so if there is any other potential problem you can advise on...

Rik · Nov 04, 2010, 15:53:30

OK, spoken to support and all looks well from their end, James. Can you explain shoutcast for me please. I know it's internet radio, but are you saying you're actually a broadcaster? The ping to your server will vary according to what's happening there, eg people are joining or leaving. Most routers also give ICMP traffic low priority, which doesn't help.

To diagnose this reliably, you do really need to drop to safe mode (and have no other machines on your network active) as anything which is uploading will affect ping times.

Interleaving is definitely part of all ADSL, in general a ping of <20ms tends to suggest fast path, but your router may actually tell you if you're on fast path or interleaved. It might be worth running routerstats on your line to see how the noise margin is swinging, burst of noise could also have this kind of effect.

http://www.vwlowen.co.uk/internet/files.htm
http://www.vwlowen.co.uk/moreinternet/files.htm

Rik · Nov 04, 2010, 15:59:37

Quote from: JamesAllen on Nov 04, 2010, 15:50:56
I notice some >100ms latency through IDNet - does this look normal to you?

Yes, the hops at 2, 4 & 6 are all typical of low ICMP priority.

Here's a couple of traces from my machine:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

tracert 213.5.180.116

Tracing route to 213.5.180.116 over a maximum of 30 hops

1 1 ms 1 ms <1 ms 192.168.1.254
2 15 ms 15 ms 14 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 14 ms 15 ms 11 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
4 16 ms 13 ms 13 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
5 25 ms 21 ms 23 ms ae-1.asd9nqp1.nl.ip.tdc.net [195.69.144.104]
6 27 ms 29 ms 27 ms xe-4-0-0.ldn4nqp1.uk.ip.tdc.net [83.88.29.21]
7 20 ms 19 ms 19 ms cpe.ge3-10.0xc3d76d8a.ldn2nxc7.customer.tele.dk[195.215.109.138]
8 27 ms 27 ms 28 ms no-rdns-yet.ohtele.com [89.238.140.113]
9 369 ms 364 ms 352 ms 213.5.180.116

Trace complete.

tracert 213.5.180.116

Tracing route to 213.5.180.116 over a maximum of 30 hops

1 <1 ms 1 ms <1 ms 192.168.1.254
2 15 ms 13 ms 27 ms telehouse-gw4-lo2.idnet.net [212.69.63.99]
3 11 ms 14 ms 13 ms telehouse-gw5-e4-400.idnet.net [212.69.63.245]
4 14 ms 13 ms 33 ms redbus-gw2-g0-1-331.idnet.net [212.69.63.5]
5 21 ms 23 ms 21 ms ae-1.asd9nqp1.nl.ip.tdc.net [195.69.144.104]
6 51 ms 27 ms 27 ms xe-4-0-0.ldn4nqp1.uk.ip.tdc.net [83.88.29.21]
7 23 ms 19 ms 23 ms cpe.ge3-10.0xc3d76d8a.ldn2nxc7.customer.tele.dk[195.215.109.138]
8 27 ms 27 ms 27 ms no-rdns-yet.ohtele.com [89.238.140.113]
9 372 ms * 314 ms 213.5.180.116

Trace complete.

JamesAllen · Nov 04, 2010, 15:59:56

Quote from: Rik on Nov 04, 2010, 15:53:30
OK, spoken to support and all looks well from their end, James. Can you explain shoutcast for me please. I know it's internet radio, but are you saying you're actually a broadcaster? The ping to your server will vary according to what's happening there, eg people are joining or leaving. Most routers also give ICMP traffic low priority, which doesn't help.

To diagnose this reliably, you do really need to drop to safe mode (and have no other machines on your network active) as anything which is uploading will affect ping times.

Interleaving is definitely part of all ADSL, in general a ping of <20ms tends to suggest fast path, but your router may actually tell you if you're on fast path or interleaved. It might be worth running routerstats on your line to see how the noise margin is swinging, burst of noise could also have this kind of effect.

http://www.vwlowen.co.uk/internet/files.htm
http://www.vwlowen.co.uk/moreinternet/files.htm

Hi Rik,

Ah no I'm just streaming to a hosted Shoutcast server that my listeners connect to. Pretty much uses about 15k of bandwidth.

Ah my router is on fast path - I telneted to it earlier and saw FAST mentioned.

Would support be able to see if there were any issues caused by interleaving being switched off? I'm starting to wonder if my side is really the problem. Did you see the new trace route I added in my last post? That shows a timeout right at the server point - not anywhere in the IDNet network.

Rik · Nov 04, 2010, 16:01:25

Quote from: JamesAllen on Nov 04, 2010, 15:50:56
It is kind of looking like the issue is with the connection at the server doesn't it.. although I have only seen this since moving so if there is any other potential problem you can advise on...

Or the routing, the second one's got 4 extra hops.

Steve · Nov 04, 2010, 16:02:16

I guess the other issue maybe that your no longer taking the same route to the server that you used to previously

Rik · Nov 04, 2010, 16:03:20

Quote from: JamesAllen on Nov 04, 2010, 15:59:56
Would support be able to see if there were any issues caused by interleaving being switched off? I'm starting to wonder if my side is really the problem. Did you see the new trace route I added in my last post? That shows a timeout right at the server point - not anywhere in the IDNet network.

It certainly looks like the server, that's the really big spike in my traces. Have a word with support and they can test the route themselves.

Rik · Nov 04, 2010, 16:04:00

Quote from: Steve on Nov 04, 2010, 16:02:16
I guess the other issue maybe that your no longer taking the same route to the server that you used to previously

Good point, Steve. Do you have a tracert from your earlier incarnation, James?

JamesAllen · Nov 04, 2010, 16:12:01

Quote from: Rik on Nov 04, 2010, 16:04:00
Good point, Steve. Do you have a tracert from your earlier incarnation, James?

Ah unfortunately I don't. A friend did a trace route for me though and is seeing similar latency.

I'm now doing a test to another shoutcast server at the same time and monitoring that for problems.

With a continuous ping to this new host I am seeing ping timeouts as I do with the other server.

Does that suggest anything or is it normal to see timeouts like this?

JamesAllen · Nov 04, 2010, 16:13:06

Quote from: JamesAllen on Nov 04, 2010, 16:12:01
Ah unfortunately I don't. A friend did a trace route for me though and is seeing similar latency.

I'm now doing a test to another shoutcast server at the same time and monitoring that for problems.

With a continuous ping to this new host I am seeing ping timeouts as I do with the other server.

However, no buffering issues so far...

Does that suggest anything or is it normal to see timeouts like this?

Steve · Nov 04, 2010, 16:14:57

If ping response is set to low priority on the server and the server is busy a timeout will occur.

JamesAllen · Nov 04, 2010, 16:16:09

Quote from: Steve on Nov 04, 2010, 16:14:57
If ping response is set to low priority on the server and the server is busy a timeout will occur.

Cool, thanks Steve.

So that is quite normal to see. I remember seeing timeouts a while ago when pinging another Shoutcast server.

The one I'm testing now had had 0 problems so far.. So maybe it is the route to the other server or just that the other one is having load issues at the moment.

JamesAllen · Nov 04, 2010, 16:37:58

Thanks for your help guys.

As soon as I started my test of streaming to another server at the same time the problematic one start behaving - typical. The pings that were consistent at 350ms or so have now dropped to 30ms again.

I'll still keep my eye on this and try to get as much data as I can on what could be causing it.

For now I'll assume it's the server that is the issue, although isn't it always the way that the day I get a new ADSL line I suddenly get these issues. Coincidence most likely..

Rik · Nov 04, 2010, 16:41:35

So many variables, James, your route into IDNet, your route to the server, server and router loads along the way. That's without bT and which way the wind is blowing.

JamesAllen · Nov 04, 2010, 16:43:54

Quote from: Rik on Nov 04, 2010, 16:41:35
So many variables, James, your route into IDNet, your route to the server, server and router loads along the way. That's without bT and which way the wind is blowing.

Really is a pain isn't it. I spoke too soon as well - suddenly got some more buffering problems.

More debugging needed me thinks...

Rik · Nov 04, 2010, 16:46:24

OK, let me get this clear in my head, James, you are uploading a datastream and you're seeing the upload pause for buffering? Have you got a bandwidth monitor installed, such as the thinkbroadband one? Does that give any clues?

JamesAllen · Nov 04, 2010, 16:49:12

Quote from: Rik on Nov 04, 2010, 16:46:24
OK, let me get this clear in my head, James, you are uploading a datastream and you're seeing the upload pause for buffering? Have you got a bandwidth monitor installed, such as the thinkbroadband one? Does that give any clues?

Yes I'm essentially uploading a constant 16k datastream to a server and also at the same time I'm listening back to that server.

I notice that when the download stream I'm listening to buffers, then a few seconds later I see send problems so it does seem to infer there is a suddenly connection problem.

Once again, now that I'm also uploading to another server at the same time I've had no issues.. I'm sure that isn't part of the problem but it's annoying when I cant rule it out.

I haven't got the thinkbroadband monitor - but that's a great idea.

Rik · Nov 04, 2010, 16:51:38

It seems an odd coincidence, and makes me think that server or routing are the issue.

JamesAllen · Nov 04, 2010, 16:55:33

Quote from: Rik on Nov 04, 2010, 16:51:38
It seems an odd coincidence, and makes me think that server or routing are the issue.

Ah luckily I just got buffering issues on the server even while the other one was being streamed to and had 0 issues.

Now I just need to work out why. Hoping that it's not something to do with the route being taken by IDNet as a friend who uses the same server never seems to get these problems - however I accept this may be a problem affecting the server today.

Again testing is critical me thinks.

Rik · Nov 04, 2010, 17:07:55

It is, James. If it proves to be a routing issue, IDNet may be able to route around for you.