MWEB Uncapped ADSL - Official Q & A

[SabreWolfy]

my point is that the problem is not what you say

As I see it, the problem is that since 14 April 2010 no Ubuntu wired or Vista wireless machine on my line (regardless of router or account) is able to successfully, reliably and in a repeatable way download "large" files to completion over HTTP, or able to resume them when they stall.

 

[TonyA]

SabreWolfy, if the rest of users have no problem downloading then why do you say problem must be with MWEB. Just downloaded (my son) 2 hd movies with no problem, average speed 300kbs (according to him).

 

[SabreWolfy]

SabreWolfy, if the rest of users have no problem downloading then why do you say problem must be with MWEB. Just downloaded (my son) 2 hd movies with no problem, average speed 300kbs (according to him).

If you've read the posts and discussion, please suggest to me where the problem lies? It has to be upstream of my router. I've used standard trouble-shooting procedures to eliminate each component of the system. The problem is not specific to only one computer. The problem persists if I use a different router and a different account. Therefore the problem is NOT one of my computers and is NOT my router and is NOT my account login. Therefore, it has to be upstream. Therefore it has to be Telkom, MWeb, SEACOM, a proxy...

 

[AntiThesis]

Well, let's stop telling him that we're all fine - he's clearly got a problem, clearly doesn't have it in for MWEB so it's unconstructive.

@Sabre: Perhaps swapping mweb accounts (so you can test on mweb uncapped through diff. accounts) would help?

 

[milomak]

As I see it, the problem is that since 14 April 2010 no Ubuntu wired or Vista wireless machine on my line (regardless of router or account) is able to successfully, reliably and in a repeatable way download "large" files to completion over HTTP, or able to resume them when they stall.

i am not saying you do not have a problem. i am saying it is not an mweb problem. it may be a problem related to mweb and settings; but seeing as no one can reproduce the problem; it seems unique to you. I do hope it is resolved. Because whatever the circumstances, they could spread.

edit: if it helps - i use debian

 

[TonyA]

Hi I'm not critising SabreWolfy, just genuinely interested in his conclusions and testing, I don't have a problem and am curious to know how he whittles it down as one day I may have to the same. His tests and experiments fascinate me at present and also seem to point to some problem outside his control. Why I wonder has no one else got this problem. Sabre Wolfy when you get sorted out please, please make sure you let the rest of us know what problem was. Good Luck

 

[SabreWolfy]

Well, let's stop telling him that we're all fine - he's clearly got a problem, clearly doesn't have it in for MWEB so it's unconstructive.

@Sabre: Perhaps swapping mweb accounts (so you can test on mweb uncapped through diff. accounts) would help?

Thanks for the comments. I have tested on MY line with someone else's router and their 1GB capped account -- same problems. Is that what you meant?

 

[SabreWolfy]

Download Stalling: WireShark Log

I put Firefox in offline mode, fired up TShark (console WireShark), started a 'wget' download and captured the output. Once the download stalled, I cancelled it and stopped TShark.

It's here, for anyone who can make sense of it. Scroll way down to the end to see the section where the download stalls:

http://pastebin.com/UsxmzjMK

 

[Gordon_R]

Thanks for the comments. I have tested on MY line with someone else's router and their 1GB capped account -- same problems. Is that what you meant?

More technical stuff: Since you are using Ubuntu, is it a standard compile? The Wikipedia article says you can get nasty side effects if you change the Window Scale Option in TCP:
http://en.wikipedia.org/wiki/TCP_window_scale_option

Because many routers and firewalls do not properly implement TCP Window Scaling, it can cause a user's Internet connection to malfunction intermittently for a few minutes, then appear to start working again for no reason.

Edit: Since you have a 384K line, there should be no reason to increase the buffer size (64KBytes). See:
http://en.wikipedia.org/wiki/Long_fat_network

 

[AntiThesis]

Thanks for the comments. I have tested on MY line with someone else's router and their 1GB capped account -- same problems. Is that what you meant?

Nah I meant another mweb uncapped account. That way you can eliminate whether it's your account specifically or the combination of your account on your line etc etc.

 

[AntiThesis]

http://pastebin.com/UsxmzjMK

This set of messages interests me:

[TCP Previous segment lost] [TCP segment of a reassembled PDU]

It occurs 224 times during your transmission - they're not really fatal errors but having so many of them is odd IIRC. @Someone with more knowledge than me - is there a limit to TCP retransmission? Is it not dying automatically at that point?

 

[SabreWolfy]

More technical stuff: Since you are using Ubuntu, is it a standard compile? The Wikipedia article says you can get nasty side effects if you change the Window Scale Option in TCP:
http://en.wikipedia.org/wiki/TCP_window_scale_option



Edit: Since you have a 384K line, there should be no reason to increase the buffer size (64KBytes). See:
http://en.wikipedia.org/wiki/Long_fat_network

Thanks, but I don't really know what those settings are about -- I'm using standard Ubuntu. Also Vista machines can't download either -- just tested again. IE reports "The connection with the server was reset".

On Tuesday last week I was downloading happily. On Wednesday I couldn't anymore.

 

[SabreWolfy]

Nah I meant another mweb uncapped account. That way you can eliminate whether it's your account specifically or the combination of your account on your line etc etc.

Well if a different router and different login still exhibit the problem, then we don't need to test this further I thought? My router and my account don't work. A different router and a different account don't work, therefore neither the router nor the account are involved?

 

[SabreWolfy]

This set of messages interests me:


It occurs 224 times during your transmission - they're not really fatal errors but having so many of them is odd IIRC. @Someone with more knowledge than me - is there a limit to TCP retransmission? Is it not dying automatically at that point?

All downloads run at maximum speed -- 38Kbps -- which implies that the line quality and connection are good; why the resends then?

 

[TonyA]

Do you still get the same problem using your account at a differrent location?

 

[SabreWolfy]

Do you still get the same problem using your account at a differrent location?

I have not tested this (yet), as I have already confirmed that downloads do not work at my location with (1) my router and my account OR (2) a different router with a different account. Therefore, we can eliminate the router and account -- therefore the problem must be the line or further upstream from the line. I have already confirmed that I am able to download at least one of the problem files at different locations with the accounts at those locations. I don't believe that testing my router/account elsewhere will tell us anything more, but I will try to test this when I'm able to.

 

[Gordon_R]

This set of messages interests me:

It occurs 224 times during your transmission - they're not really fatal errors but having so many of them is odd IIRC. @Someone with more knowledge than me - is there a limit to TCP retransmission? Is it not dying automatically at that point?

Thanks, but I don't really know what those settings are about -- I'm using standard Ubuntu. Also Vista machines can't download either -- just tested again. IE reports "The connection with the server was reset".

On Tuesday last week I was downloading happily. On Wednesday I couldn't anymore.

Sorry to grind through the technical stuff, but its worth eliminating as many factors as possible.

All downloads run at maximum speed -- 38Kbps -- which implies that the line quality and connection are good; why the resends then?

You can still get 99% of line speed, but have 'bursts' of errors which cause your line to reset. Though this doesn't explain why the file gets stuck at the same point each time...

It may be that the transparent proxy cache downloads 6MB (or whatever), and you think you are still connected, but the original server has long since disconnected.

It is highly possible that MWeb changed the settings on the proxy cache during the last few days (they haven't even publicly stated what kind of caching they do).

Edit: It is also possible that your line quality degraded around this time.

I have not tested this (yet), as I have already confirmed that downloads do not work at my location with (1) my router and my account OR (2) a different router with a different account. Therefore, we can eliminate the router and account -- therefore the problem must be the line or further upstream from the line. I have already confirmed that I am able to download at least one of the problem files at different locations with the accounts at those locations. I don't believe that testing my router/account elsewhere will tell us anything more, but I will try to test this when I'm able to.

I think you have narrowed down the problem considerably, that it may be some interaction between the ADSL line and the ISP. How do your line noise and SNR ratios look?

 

[SabreWolfy]

<snip>How do your line noise and SNR ratios look?

Thanks for the feedback. I've seen posts with such data in this thread -- how do I find that out?

Edit: Found it.

 

[SabreWolfy]

What does it mean? From my limited knowledge it seems high? Port was reset by MWeb on Friday.

			Downstream		Upstream
SNR Margin 		34.0 dB 		12 dB
Line Attenuation 	41.5 dB 		23.5 dB
CRC Errors	 	3 			0
Latency 		Fast 			Fast

 

[SabreWolfy]

Called Telkom to reset the line. They say the 41.5 dB is "fine". I've now wasted days on this problem. There seems no solution Man I'm fed-up