another question

Chowley

Im lost.
What is rate adaptive??
And.
Interleaving.:rolleyes:

melachi

google interleaving:
http://www.dslreports.com/shownews/184

perhaps you can find the answer for the other term

Chowley

What is first hop?

People talk about getting a bad ping on theyre first hop what does that mean??

Tenshot

Originally posted by Chowley
Im lost.
What is rate adaptive??
And.
Interleaving.:rolleyes:

Rate Adaptive: instead of requiring a fixed speed like 1 Mb, rate adaptive tries to get the best available speed between two ranges (e.g. 256Kb-512Kb), not too different from the way a V.90 modem will try and get a 56K connection if possible but may end up at 28.8K on dodgy lines.

Each ADSL frame transmitted includes some extra error correction info so that small errors can be corrected automatically without needing a retransmission. (Retransmissions happen at the TCP/IP level, which is quite inefficient, so you want to avoid them if possible.)

Fast mode just sends one frame at a time. If a big burst of noise happens, the error correction info can't compensate so the frame is lost.

Interleave mode sends several frames in parallel: a byte from the first frame, a byte from the second frame, and so on. The idea is that a burst of noise will now hopefully cause small damage to several frames instead of big damage to one frame, and so the error correction has a better chance of recovering.

The downside is that if the noise burst is too big, then you still can't recover the data and now you've lost all of the interleaved frames instead of just a single fast frame (i.e. more data to resend). The more frames you interleave, the more reliable it is (but the more data you lose with a really big burst of noise). Yesterday, someone posted a link to a research paper which concluded that if you're going to use interleaving at all, you really need to use 32-way or 64-way interleaving, otherwise the types of errors you see on real DSL lines tend to exceed the ability of the error correction code to recover.

Anyway, the final bit of the equation is latency: how long it takes a single packet to get from one side of the DSL link to the other. With fast mode, only a single 256-byte ADSL frame gets transmitted so it's pretty, um, fast (around 4 ms at 512 KB/s). With 16-way interleave, you'd need to send 16 frames to get that packet across, even if 15 of them are empty. On a 512 KB/s link, that works out around 64 ms which is a lot slower.

(If you're running ping tests, you need to account for the return time as well, which will be at 128 KB/s and thus take four times longer.)

Note that both interleaved and fastmode transmit data at the same average speed over time, it's just that it gets there by a slightly longer path with interleaved. Normally that's not a big problem unless you're doing something that has a lot of back-and-forth interaction, like realtime gaming.

Incidentally, from the latency calculations above, it sounds like those reporting 30ms ping times (probably about 20ms to the BAS on the far end of the DSLAM) must be running with an interleave factor of 1, which is essentially just fast mode: 4ms + (4*4ms) = 20ms. The 1 MB/s customers are seeing about 40-50s ping times which would be 80-100ms at 512KB/s, suggesting the interleave setting is 4.

Maybe all the concern about not having fast-mode available on the residential service isn't such a big deal after all?

Coyote

try not post 2 threads
Tenshot gave you most of the info you need
as for the first hop when some info is sent from
your pc to a server it travels across a number of
routers each is known as a hop when counting how many
it takes to get to a server on the net.
some take more time some take less.
the more hops and the higher the ping the longer it takes.

when people are talking about the speed of the first hop.
they mean how fast or slow there connection is to start with
the first hop on
56K = 150ms
ADSL= 50ms
ISDN = 20/30ms
lease line = 5/10ms

each hop adds more time to the total, so less = better.

Coyote

Chowley

Thanks Tenshot and Coyote
but how does the ISDN have a better ping than ADSL?

flav0rflav

Originally posted by Tenshot
Each ADSL frame transmitted includes some extra error correction info so that small errors can be corrected automatically without needing a retransmission. (Retransmissions happen at the TCP/IP level, which is quite inefficient, so you want to avoid them if possible.)
[/B]

Bollix, as in Asterix and Obelix, as in pure fiction.
TCP/IP is designed to handle packet loss, has been and always will.

Originally posted by Tenshot
Yesterday, someone posted a link to a research paper which concluded that if you're going to use interleaving at all, you really need to use 32-way or 64-way interleaving, otherwise the types of errors you see on real DSL lines tend to exceed the ability of the error correction code to recover.

Which increases the delay hugely, in fact, it increases it to the level where it interferes with TCP ability to flow control and window, which is also in the paper, and led to the conclusion, that interleaving was pointless.

Now don't make me go and get the Foghorn Leghorn avatar.

Tenshot

Originally posted by flav0rflav
Bollix, as in Asterix and Obelix, as in pure fiction.
TCP/IP is designed to handle packet loss, has been and always will.

Of course TCP/IP can handle packet loss; who said it couldn't?

What I said was that if you lose a packet on a single hop, it's inefficient to rely on TCP/IP to recover. Assuming only a single packet was lost, the sender will wait for at least three more ACKs (with TCP/IP's fast retransmit algorithm) before it gets around to retransmitting the lost data. With a much slower return path for the ACKs (e.g. 128 Kbps), the sender's TCP window can close resulting in dead bandwidth.

If two or more packets were lost in one go -- which is quite possible; a single lost ADSL frame with four ATM cells has about a 10% chance of spanning two 1500-byte IP packets -- then TCP's fast retransmit algorithm won't work so well and may fall back on timeouts, which is worse again.

Now, if you can recover the packet at the point where it was lost, you cut out all the retransmissions etc across the rest of the network which is obviously more efficient. (I'll conveniently ignore the cost of the recovery itself.)

Which is not to say that TCP/IP does a bad job - it does an excellent job given the constraints it works under. I do agree though that an interleave of 32+ for TCP/IP would be a complete waste of time.

http://vvv.it.kth.se/docs/Reports/DEGREE-PROJECT-REPORTS/990615-Bandula-Vedage.pdf has some good discussion.

Tenshot

Originally posted by Chowley
Thanks Tenshot and Coyote
but how does the ISDN have a better ping than ADSL?

ISDN usually sends data at 64 Kbps, and it sends only as much data as is needed for the particular packet. A standard ping packet is about 80 bytes with headers, or 640 bits. At 64000 bits per second, that takes 10ms to transmit. Another 10ms to receive the reply, add a bit for network overhead and you should see ping times in the range of 20-30ms.

flav0rflav

Originally posted by Tenshot

http://vvv.it.kth.se/docs/Reports/DEGREE-PROJECT-REPORTS/990615-Bandula-Vedage.pdf has some good discussion.

hmmm, "The word interleaving does not appear in this document"

He does not consider a delay larger than 10 ms for the link. He does mention the delay-bandwidth product but didn't quite get as far as the other research paper. And he causes the delay using his test equipment, not interleaving on the dsl line. Otherwise a nice paper.

Tenshot

Originally posted by Tenshot
Incidentally, from the latency calculations above, it sounds like those reporting 30ms ping times (probably about 20ms to the BAS on the far end of the DSLAM) must be running with an interleave factor of 1, which is essentially just fast mode: 4ms + (4*4ms) = 20ms. The 1 MB/s customers are seeing about 40-50s ping times which would be 80-100ms at 512KB/s, suggesting the interleave setting is 4.

I got to wondering why some of the ESat DSL customers were reporting ping times of ~10ms, so I did some more reading. It turns out that ADSL frames are 256 bytes at 8 MB/s only; my earlier calculations were way off.

These appear to be the correct minimum figures for pinging across a fast-mode DSL connection:

1024K / 256K --> 4.42 ms
 512K / 256K --> 5.16 ms
 512K / 128K --> 8.36 ms

(If you're not interested in the details, now is a good point to stop reading.)

To figure this out, I went to the source: ITU-T recommendation G.992.1, which is the official standard for ADSL DMT. This is available from http://www.itu.int/itudoc/itu-t/rec/g/index.html if you register (free for the first three downloads). It's heavy going, so here's the condensed version.

DSL speeds always refer to the total number of data bits sent per second. DSL protocol and error correction overhead is counted separately and doesn't affect this figure, so it can be safely ignored. (This means a 512Kb/s link is actually sending more like 540-550 Kb/s down the wire when the extra overhead is taken into account.)

ADSL always sends 4000 data frames per second in each direction. The size of each frame is dependent on the bitrate. Each frame takes exactly 0.246ms to transmit; faster bitrates mean more bits per frame. (There is also one sync frame for every 68 data frames.)

At 4000 frames per second, this is the number of bytes per data frame at common speeds:

 128 Kb/s: 4 bytes per frame (= 128000 / 4000 / 8)
 256 Kb/s: 8 bytes per frame
 512 Kb/s: 16 bytes per frame
1024 Kb/s: 32 bytes per frame

Now, a standard ping fits neatly into two ATM cells. Each ATM cell is 53 bytes so two cells occupy 106 bytes. Dividing this by the frame size gives the number of frames required to send the ping. Multiply this by the frame transit time (always 0.246 ms) to get the time to send the ping in one direction:

 128 Kb/s: 106/4 = 27 frames = 6.64 ms
 256 Kb/s: 106/8 = 14 frames = 3.44 ms
 512 Kb/s: 106/16 = 7 frames = 1.72 ms
1024 Kb/s: 106/32 = 4 frames = 0.98 ms

The fast-mode figures in the table at the start came from adding the upstream and downstream transit times together (e.g. 1024K/256K = (0.98 + 3.44) = 4.42 ms). Occasionally, a sync frame may get sent between two of the data frames which will add an extra 0.25ms or so.

Now, this only measures the time spent crossing the DSL link. G.992.1 says that the total transmit time for a single frame can be up to 2 ms (including encode and decode time at each end). In practise, I'd expect modern chipsets can encode and decode pretty rapidly so any additional overhead due to this should be minimal. At most, it will add an additional (2 - 0.25) * 2 = 3.5 ms to the roundtrip time.

So far so good. Now what about interleave mode? Well, the interleave factor can be set to 1, 2, 4, 8, 16, 32 or 64. If we assume an interleave factor of 2, a 512K / 128K link gets a round trip time of (8.36 * 2) = 16.72 ms. This is pretty close to the ~20ms figure Eircom RADSL users have been reporting.

How about the other users at 1024K/256K? Well, the fastest ping response I've seen on such a line is 47ms.
8x interleave gives (4.42 * 8) = 35.36ms which is too fast, 16x interleave is 70.72ms which is too slow.

But wait: G.992.1 has a small note that says the upstream interleave value is limited to 8x. Assigning 16x to the downstream channel and 8x to the upstream channel gives (0.98 * 16) + (3.44 * 8) = 43.2ms which is definitely in the right ballpark for an overall ping response of 47ms. (On an interleaved link, ping times tend to fluctuate more because your ping packet might be unlucky and have to wait for the previous interleaved frame to finish sending before a new one can begin.)

In summary then (for those of you who made it this far), it looks like Eircom are using 2x interleave on the RADSL service and 16x/8x interleave on the iStream service. Fast mode is about twice as fast again (as demonstrated by ESat customers).

MadsL

Jaysus, talk about a surfeit of riches....way to confuse a newbie!

...nontheless excellent post guys, I'll wait for the Broadband Chair of all Human Knowingness to be granted to Tenshot or flav0rflav!!!

One tiny quibble...

Fast mode is about twice as fast again (as demonstrated by ESat customers).

ONLY ADSL Esat customers (40 exchanges) - the rest is plain vanilla RADSL a la eircom. Do not go assuming fast ping times for IOL Broadband, they are happily telling everybody that interleaving is off...as we know this is not necessarily so.

Tenshot

Originally posted by MadsL
One tiny quibble... ONLY ADSL Esat customers (40 exchanges) - the rest is plain vanilla RADSL a la eircom. Do not go assuming fast ping times for IOL Broadband, they are happily telling everybody that interleaving is off...as we know this is not necessarily so.

Oops -- good point! Thanks for clarifying.

(I finally found the ESat DSL details online just now at home.iol.ie instead of www.esat.ie -- doh!)

flav0rflav

Nice one!

I was planning to have a look at those docs! We'll assume ANSI and .Lite are almost identical? One small point is the bit about the number of frames, re the size of a ping. Eircom RADSL is using PPPoEoA, adding a not inconsiderable amount of overhead. Hmm, don't have the numbers to hand right now(will edit! - oE has 22 more bytes for VcMux'd, 26 for LLC). But Esats own DSLAM ADSL is running PPPoA, I believe, which has considerably less overhead.

Yes, indeed, the details are nailed! The conclusions on the most desirable setups (line speed, rate limiting, contention, latency, bandwidth) should follow. I might start another thread, as this stuff really is just getting tagged on at the bottom of random discussions. But maybe not today.

edit:
PPPoEoA Stack
<payload> [0 - 1492]
PPP [ 2]
PPPoE [ 6]
Ethernet [ 14]
Rfc1483 Bridged [ 2 or 10] [VcMux or LLC (=default)]
AAL5 [ 8]
ATM

PPPoA Stack
<payload> [0 -65533]
PPP [ 1 or 2] [compressed or uncompressed]
PPPoA [ 0 or 4] [VcMux (=default) or LLC]
AAL5 [ 8]
ATM

BlackFlag

Originally posted by Chowley
Thanks Tenshot and Coyote
but how does the ISDN have a better ping than ADSL?

I ahve switched from ISDN to ADSL and ADSL pings between 10-40 better in game...depends on amount and time of game.
and for d/l etc ADSL blows away ISDN

Tenshot

Originally posted by flav0rflav
One small point is the bit about the number of frames, re the size of a ping. Eircom RADSL is using PPPoEoA, adding a not inconsiderable amount of overhead.

Erk! I forgot about the MAC header in PPPoE. Let's see what it does to the ping:

Ping data [32 bytes]
ICMP header [8]
IP header [20]
PPPoE stuff [8]
MAC header [14]
Bridged1483 encap [10]
AAL5 header [8 bytes]

This comes out at 100 bytes, which is just fractionally over the 96-byte capacity of two ATM cells. So, it will need three cells, which is a pity because it messes up my earlier calculations no end! Tricky business this...

I asked a friend with RADSL to do some short pings (-l 16 option) to see the effect of dropping down to two ATM cells. Sure enough, he says he is now seeing ping responses around 14-16ms instead of 19-22ms as previously. However, when I did the same test on my 1M line, it made no difference.

So, let's try the calculations again. With data size = 159 bytes (3*53), raw fast-mode transit times are:

 128 Kb/s: 159/4  = 40 frames = 9.84 ms
 256 Kb/s: 159/8  = 20 frames = 4.92 ms
 512 Kb/s: 159/16 = 10 frames = 2.46 ms
1024 Kb/s: 159/32 =  5 frames = 1.23 ms

The fast-mode ping response times should then look like this:

1024K / 256K --> 6.15 ms
 512K / 256K --> 7.38 ms
 512K / 128K --> 12.30 ms

Okay, so let's revisit the interleave stuff again, this time a bit more carefully:

At RADSL speeds, assuming 2x interleave, frames need to be sent in pairs. The 10 frames for the 512K link should be okay as five pairs (though it might need six pairs if the initial frame arrives when another frame is being transmitted). The 40 frames for the return path will also be fine (20 or 21 pairs). This would suggest that at 2x interleave, the ping times would actually be close to normal fast-mode.

What about 4x interleave? Now frames are sent in groups of four, so those 10 frames at 512K will need either three groups or four groups (depending on initial frame alignment). For the 128K return path, 40 frames will require at best 10 groups, at worst 11 groups. So, the total frames sent will be in the range (12+40) to (16+44), or 52 to 60. Multiplying by the frame time of 0.246 ms gives a range of 12.792 ms to 14.76 ms. This is still too quick.

What about 8x? The same logic says the low bound will be (16+40) frames with a high bound of (24+48) frames, or 13.77ms to 17.7ms. This is getting closer, but not quite there yet. 16x doesn't help either (the upstream has to stay at 8x since it can't go any higher). 32x gives us the numbers we want : (32 + 40) * 0.246 = 17.7ms best case, (64 + 48) * 0.246 = 27 ms worst case but can't be right because now the numbers for two-cell pings are too slow as well.

And at 1M, the figures make even less sense since even at 64x interleave, it looks like your worst case would be (64+64) frames downstream and (8+8+8+8) frames back upstream for a total of 160 frames which is 39.36ms - and that's a long way from the 47ms best case I've seen in real life.

Hmm... need to go and do some more reading I think.

(I do agree that we've drifted slightly off the original topic...)