Very good ADSL sync rate and attenuation but download speed is only ~ 75%

Forums › Spark New Zealand (including Skinny and BigPipe) › Very good ADSL sync rate and attenuation but download speed is only ~ 75%

tcpdump

311 posts

Ultimate Geek

#102436 15-May-2012 21:44

Hi,

I am a Telecom Broadband customer and live very close to a cabinet.
The DSL sync rate is:

> adsl status
--------------------------- ATU-R Info (hw: annex A, f/w: annex A) -----------
DSL Modulation : ADSL2+(G.992.5)
State : SHOWTIME
DS Actual Rate : 21206755 bps US Actual Rate : 1009032 bps
DS Attainable Rate : 21120000 bps US Attainable Rate : 1009000 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 7 dB Cur SNR Margin : 12 dB
DS actual PSD : 16. 4 dB US actual PSD : 12. 1 dB
ADSL Firmware Version : 332201_A
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 2 dB Far SNR Margin : 11 dB
CO ITU Version[0] : 00004244 CO ITU Version[1] : 0000434d
DSLAM CHIPSET VENDOR : < BDCM >
>

I use PPPoA to PPPoE passthrough (the modem is a Vigor 120) and PPPoE is managed either by an ASUS RT-N16 or a linux machine.
The maximum download speed reached is 2.15MB/sec which would translate to 17.2Mbit/sec (from zeus.jetstream.co.nz download test website).

The wiring seems to be fine, I have no phones connected (as I don't use the landline) or alarm, sky or other suspects. The only thing plugged into the telephone line is the modem.

I've tried several modems/routers (Telecom provided TG585, a Linksys WAG3000 and the Vigor 120) with similar results although the Vigor looks to be the best so far.

Any thoughts?

Thanks.

Talkiet

4792 posts

Uber Geek

Trusted

#625791 15-May-2012 21:53

It's the way TCP works.

Seriously.

The moment your stack detects a dropped packet it backs way the heck off and then builds back up again... achieving 75% throughput on an unshaped TCP connection is pretty close to perfectly expected behaviour.

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

tcpdump

311 posts

Ultimate Geek

#625811 15-May-2012 22:17

That may explain it. Would you be able to point to an article that describes this in more in depth?

Is it worth to mess around with the MTU?

I never noticed this in the ethernet world but then again, on ethernet you don't normally have too many dropped packets.

Thanks.

Talkiet

4792 posts

Uber Geek

Trusted

#625813 15-May-2012 22:25

tcpdump: That may explain it. Would you be able to point to an article that describes this in more in depth?

Is it worth to mess around with the MTU?

I never noticed this in the ethernet world but then again, on ethernet you don't normally have too many dropped packets.

Thanks.

http://www.cs.cmu.edu/~dga/15-441/F08/lectures/19-tcpperf.pdf

Or of course RFC5681.

Note that the PDF suggests 75% and then debunks (to some extent) it as a theoretical construct not applicable to many real world situations. That was what I was alluding to with my hopelessly simplistic "unshaped" comment.

Basically though your connection is fine. If you can find a way to conduct a UDP test from a remote site with enough bandwidth you'll probably get very close to 100% throughput if you're getting that much over TCP.

Cheers -N

ps... No, I wouldn't change a thing about your connection.

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#625856 16-May-2012 06:23

You also need to remember sync rate doesn't equate to actual maximum throughput. There are plenty of variables.

tcpdump

311 posts

Ultimate Geek

#625932 16-May-2012 10:16

Understood, thanks a lot for the clarification.

Cheers.

mercutio

1392 posts

Uber Geek

#627675 19-May-2012 11:52

i'd actually disagree and say that a lot of what you're seeing is the adsl overhead. sync rate doesn't mean throughput.

on top of that tcp/ip has overhead..

tcp/ip on ethernet tends to go up to around 92% of connection speed. like 920 megabit on gigabit... leading to up to 115megabytes/sec.

on adsl if you had 20megabit actual throughput, you'd be looking at up to around 92% of 20.. or around 18.4 megabit.. or 2355k/sec.. although the latency can mean any packet loss is way worse.. and that it takes a while to get up to speed.

i'm also guessing that overhead is slightly higher.. leaving you less than 20 megabit throughput. (it can also vary by packet size)

on my adsl2+ connection for comparison i get around 1965k/sec on 19579 sync rate, which is around my "divide by 10, not 8" rule for overhead. from my own testing if i use iperf and send 16megabit of traffic the connection tends to lock up but 15 megabit is fine, and there is no packet loss.

national:
[ 3] 0.0-10.0 sec 17.9 MBytes 15.0 Mbits/sec 0.076 ms 0/12755 (0%)
[ 3] 0.0-10.0 sec 18.6 MBytes 15.6 Mbits/sec 0.051 ms 357/13606 (2.6%)

international:
[ 4] 0.0-10.0 sec 17.9 MBytes 15.0 Mbits/sec 0.100 ms 0/12755 (0%)

fwiw, if you want me to send you traffic with iperf from international or national i can. you need to do a udp port forward (i usually do tcp/ip at same time so i can do tcp test too, in parallel is available too) and allow firewall to pass through an ip address or two, and then you run iperf -s for tcp or iperf -s -u for udp i use -i 1 on the end to see per second statistics. there are both windows and linux versions, but i've found that the windows version doesn't seem to work on gigabit lans that efficiently. (should be fine for internet)

with iperf in tcp mode: "iperf -s -i 1" you'll get results something like:

[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 1.90 MBytes 15.9 Mbits/sec
[ 4] 1.0- 2.0 sec 1.94 MBytes 16.3 Mbits/sec
[ 4] 2.0- 3.0 sec 1.94 MBytes 16.3 Mbits/sec

While the first second of data transfer is slower. (low ping -- no interleaving and auckland to auckland) makes it less apparent on national, it's still there.

It's a bit easier to see it on international.

[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 748 KBytes 6.13 Mbits/sec
[ 4] 1.0- 2.0 sec 887 KBytes 7.27 Mbits/sec
[ 4] 2.0- 3.0 sec 980 KBytes 8.03 Mbits/sec

That's the same international host that can do 15megabit with udp. So distance etc can make a difference to tcp/ip irrespective of available bandwidth. it's not until 2 to 3 seconds that it goes over 50% of your bandwidth. And most web requests are smaller than that so don't get anywhere near max size, although web sites make up for it by having lots of seperate files, this can mean burst noise and packet loss, or buffer bloat. Either of which can make the connection feel slow. This tends to be much less of a problem at 20 megabit though.

Napster

202 posts

Master Geek

#628387 21-May-2012 15:02

From experience with high ADSL2+ sync speeds. Telecom somehow have a hardcap of 19mb/s.

ADSL2+ sync with SNR tuned was 26mb/s = 19mb/s throughput on Telecom's network.

The day i switched over to Snap i broke right past that and was hitting 23 -24mb/s no problem.

So far iv only seen this affect on Telecom and Xnet.