download speed discrepency

[vortmax]

I'm facing an intersting issue with download speeds on a cable network. We run a small residental HFC network off of a T-1 line. There is a single NAT at the gateway to the internet. The QOS for the line is 900 Kbps up and down per subscriber. One customer is reporting that he can only manage download speeds on the order of 20 Kbps which will sometimes burst to 200 Kbps. This is consistant among different downloads, including ones from well maintained servers (including mozilla ). The odd thing is, running any number of speed tests (from sites like speedtest.net) show the connection to be running at the QOS throttle.

So testing shows the connection to be running up to speed, but in practical use, the connection crawls.

I did have the customer run a NDT connection test (

http://miranda.ctd.anl.gov:7123/)

which showed nothing abnormal, except a server to client cacheing of about 90%. This number did manage to decrease to around 60%, but that is still abnormally high. Client to server caching wasn't as high, but still in the 20's.

At the time of these tests, the bandwidth in use on the line was minimal (less then 30%), so congestion should not be an issue. As far as know, this is the only customer experiencing this problem as well.

Any thoughts as to what could be causing this? I suspect the firewall/gateway due to the high packet caching, but we run this identical set up on other properties with 10x the number of clients and don't experience this issue.

 

[jimbopalmer]

Important question: What OS is that customer running? Many older MS operating systems have a very small RWIN value stock.

I would run the DSLREPORTS.COM tweak test to see if his RWIN is too small and increase it.

http://www.dslreports.com/tweaks

http://www.dslreports.com/drtcp

I tried to remain child-like, all I acheived was childish.

 

[vortmax]

Both machines he has tried we XP

 

[vortmax]

Here is a traceroute I had him do

Tracing route to candc-ea.gamespy.com [207.38.11.160]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 10 ms 11 ms 10 ms 192.168.200.1
3 15 ms 11 ms 11 ms ***.***.***.*** (our public IP)
4 870 ms 594 ms 727 ms 12.87.65.189
5 771 ms 1006 ms 760 ms tbr2.cgcil.ip.att.net [12.123.4.238]
6 701 ms 875 ms 756 ms ggr2.cgcil.ip.att.net [12.123.6.25]
7 953 ms 876 ms 917 ms 192.205.33.210
8 661 ms 571 ms 712 ms ae-32-54.ebr2.Chicago1.Level3.net [4.68.101.126]

9 690 ms 810 ms 676 ms ae-78.ebr3.Chicago1.Level3.net [4.69.134.62]
10 897 ms 573 ms 718 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
11 726 ms 710 ms 951 ms ae-1-100.ebr1.Denver1.Level3.net [4.69.132.37]
12 577 ms 679 ms 491 ms ae-3.ebr2.SanJose1.Level3.net [4.69.132.57]
13 545 ms 585 ms 675 ms ae-62-62.csw1.SanJose1.Level3.net [4.69.134.210]

14 578 ms * * ae-63-63.ebr3.SanJose1.Level3.net [4.69.134.225]

15 * * * Request timed out.
16 ^C


Tracing route to candc-ea.gamespy.com [207.38.11.160]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 11 ms 9 ms 9 ms 192.168.200.1
3 12 ms 11 ms 21 ms ***.***.***.*** (our public IP)
4 66 ms 22 ms 99 ms 12.87.65.189
5 25 ms 24 ms 25 ms tbr2.cgcil.ip.att.net [12.123.4.238]
6 22 ms 23 ms 21 ms ggr2.cgcil.ip.att.net [12.123.6.25]
7 24 ms 23 ms 21 ms 192.205.33.210
8 31 ms 35 ms 55 ms ae-32-54.ebr2.Chicago1.Level3.net [4.68.101.126]

9 24 ms 35 ms 22 ms ae-78.ebr3.Chicago1.Level3.net [4.69.134.62]
10 63 ms 54 ms 54 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
11 64 ms * 61 ms ae-1-100.ebr1.Denver1.Level3.net [4.69.132.37]
12 78 ms 75 ms 73 ms ae-3.ebr2.SanJose1.Level3.net [4.69.132.57]
13 77 ms 73 ms * ae-62-62.csw1.SanJose1.Level3.net [4.69.134.210]

14 * * * Request timed out.
15 * 84 ms * ae-2.ebr3.LosAngeles1.Level3.net [4.69.132.10]
16 * * * Request timed out.
17 76 ms 78 ms 74 ms ae-13-69.car3.LosAngeles1.Level3.net [4.68.20.5]

18 85 ms 95 ms 85 ms MYSPACE-INC.car3.LosAngeles1.Level3.net [4.71.32
.38]
19 80 ms 74 ms 75 ms vl341.cs1.lax1.myspace.com [204.16.35.133]
20 77 ms 134 ms 78 ms 69.10.20.254
21 78 ms 77 ms 77 ms 69.10.20.246
22 97 ms 101 ms 88 ms 207.38.11.160


The first trace was done while he was downloading (at 20K) from that server. The second was done after the download was canceled. Looking at that, it appears the latency spike is between the T1 router and the next router. It's not like there is a trans-Atlantic crossing between the T1 router and the next router, so I'm about ready to call our ISP and see what's up.

 

[jimbopalmer]

1 <1 ms <1 ms <1 ms 192.168.0.1
2 11 ms 9 ms 9 ms 192.168.200.1

For some reason, you appear to have multiple NAT routers at your site. This is never ideal. Any idea why?

I tried to remain child-like, all I acheived was childish.

 

[jimbopalmer]

Actually, if you reduce his RWIN, his downloads will be less saturating and other traffic can get through, but his downloads will take longer. Just saying.

Improving his download speed will fill the pipe more completely and get him done sooner, but less other traffic can fit in the spaces. Note that if this is P2P it never gets 'done' and he never gets better.

I tried to remain child-like, all I acheived was childish.

 

[vortmax]

That double nat is caused by his router. His modem is given a 200.xxx IP address. He did try it without the router, so that his computer was taking the 200. IP and while latency was lower, the results were the same. Download tests showed fast but actual downloads were slow.

The traceroutes shown were with a smaller rwin as advised by the dslreports test. From the few tests he did, the new rwin did speed up his connection some, but not dramatically.