MWEB Uncapped ADSL - Official Q & A

Status
Not open for further replies.
SabreWolfy said:
Thanks for the suggestion -- I'm familiar with FDM, but's Win32. I don't think a download manager will help though. I've tested with wget, Firefox and Chrome. The download simply drops to 0kbps and stalls. If I try to resume the download with wget (which is the kind of thing FDM would do), it does not even connect to the site. Starting it from scratch again does work, but then in stalls again later on.
Click to expand...

No FDM is nothing like wget. And browser downloaders, even Firefox and Chrome, are not multithreaded. FDM provides multithreaded downloads which are super fast, reliable, and resumable. Don't even think about doing http downloads reliably without a multithreaded download manager, like FDM or Orbit.
 
Gatecrasher said:
No FDM is nothing like wget. And browser downloaders, even Firefox and Chrome, are not multithreaded. FDM provides multithreaded downloads which are super fast, reliable, and resumable. Don't even think about doing http downloads reliably without a multithreaded download manager, like FDM or Orbit.
Click to expand...

I'm aware that FDM is multithreaded. If wget downloads are coming down at 38Kbps, multithreading will simply get two threads at 19kbps, or four threads at 9kbps. Regardless, something is wrong somewhere if wget, Firefix, Chrome, etc. can't download a file. Still, it may be worth seeing how the problem manifests under a multithreaded download. I'll try to test it out later today when I'm home.

As I've mentioned before, the downloads won't resume at all for some reason. Wget resumes the download, as any downloader has to, by using the RANGE HTTP header. For some reason, this does nothing after the download has stalled. However, FDM may use a different byte range, which may allow the download to resume.
 
SabreWolfy said:
I'm aware that FDM is multithreaded. If wget downloads are coming down at 38Kbps, multithreading will simply get two threads at 19kbps, or four threads at 9kbps. Regardless, something is wrong somewhere if wget, Firefix, Chrome, etc. can't download a file. Still, it may be worth seeing how the problem manifests under a multithreaded download. I'll try to test it out later today when I'm home.

As I've mentioned before, the downloads won't resume at all for some reason. Wget resumes the download, as any downloader has to, by using the RANGE HTTP header. For some reason, this does nothing after the download has stalled. However, FDM may use a different byte range, which may allow the download to resume.
Click to expand...

You're on Linux? If so, you could try something like this:
http://dfast.sourceforge.net/
 
@Auntpol - Yip been there, I hit the FUP around 15GB roughly and was on turtle net for days til about the 14th. Since then its been getting good speeds, for how long we shall see!

@xrapidx - LOL, trust me I am in no way affiliated to Afrihost nor am I an employee. Just a soon to be ex-customer who canceled due to struggling with their support and service. Perhaps my account is no longer being throttled in hope that I may reconsider the cancellation, but that would be a presumption and I'd be wrong in doing so.

Don't get me wrong, I am now a MWeb customer and I'm holding thumbs they do provide a better service overall. I ,and many others I'm sure, will be most loyal customers to MWeb as long as its warranted by great service delivered to me/us.
 
SabreWolfy said:
I'm aware that FDM is multithreaded. If wget downloads are coming down at 38Kbps, multithreading will simply get two threads at 19kbps, or four threads at 9kbps. Regardless, something is wrong somewhere if wget, Firefix, Chrome, etc. can't download a file. Still, it may be worth seeing how the problem manifests under a multithreaded download. I'll try to test it out later today when I'm home.

As I've mentioned before, the downloads won't resume at all for some reason. Wget resumes the download, as any downloader has to, by using the RANGE HTTP header. For some reason, this does nothing after the download has stalled. However, FDM may use a different byte range, which may allow the download to resume.
Click to expand...

This may be totally off topic, but does your problem occur on local or international downloads? I was just reading about TCP window scale option and Long Fat Networks. This could also be something to do with the MWeb transparent proxy cache.
 
SabreWolfy said:
For anyone who can make sense of the detailed debug server-header logs from wget, here they are.

Starting a download from scratch: http://pastebin.com/w0Bj93YF

After it stalled, I ran wget again to resume/continue the download: http://pastebin.com/W9YcqAra
Click to expand...

Everything looks normal - does it just sit at line 152 on your second link when you try to resume the wget?

Could you try download it from http://www.codemonkeys.co.za/pod/ ?

I've set logging on so perhaps there'll be a clue there.
 
Last edited:
AntiThesis said:
Everything looks normal - does it just sit at line 152 on your second link when you try to resume the wget?

Could you try download it from http://www.codemonkeys.co.za/pod/ ?

I've set logging on so perhaps there'll be a clue there.
Click to expand...

Just brought my parents' router here to test -- logged on with their 1GB capped 384 account with their router on my line -- and the download stalled at 2.5MB and would not resume!

Downloading the file from your link with wget in debug mode back on my router and account on my line.

Stalled: http://pastebin.com/rXaVUxaw

Resume attempt: http://pastebin.com/Mp2BpeNp
 
Last edited:
Gordon_R said:
This may be totally off topic, but does your problem occur on local or international downloads? I was just reading about TCP window scale option and Long Fat Networks. This could also be something to do with the MWeb transparent proxy cache.
Click to expand...

I've tried it on several downloads from local and international sites. I'm becoming more convinced that it has to do with the MWeb cache. I downloaded a test file successfully on a capped MWeb account across town. However, trying a test file on MY line with a different router and different capped MWeb account resulted in a stalled file. Therefore, we now know that it has NOTHING to do with my hardware, computer, network cards, router or account. It there HAS to be the line (how? it downloads at 38kpbs when it starts) or something further upstream from me -- that is, Telkom, MWeb, proxies?
 
Yeah look, everything seems normal. Over to MWEB! :D

Only thing I can think of is something funky with their cache. Like I said - I had the same thing with DigiChilli for a while but they tanked before the issue could be resolved.
 
AntiThesis said:
Yeah look, everything seems normal. Over to MWEB! :D

Only thing I can think of is something funky with their cache. Like I said - I had the same thing with DigiChilli for a while but they tanked before the issue could be resolved.
Click to expand...

Thanks for your help. I hope they find the problem soon. It's so frustrating! :mad:

Edit: The smallest of the files that are stalling is 6.1MB. I successfully downloaded an mp3 podcast of 2.8MB now. Tried the 6.1MB again and it stalled as normal. Maybe related to file size?
 
Last edited:
SabreWolfy said:
I've tried it on several downloads from local and international sites. I'm becoming more convinced that it has to do with the MWeb cache. I downloaded a test file successfully on a capped MWeb account across town. However, trying a test file on MY line with a different router and different capped MWeb account resulted in a stalled file. Therefore, we now know that it has NOTHING to do with my hardware, computer, network cards, router or account. It there HAS to be the line (how? it downloads at 38kpbs when it starts) or something further upstream from me -- that is, Telkom, MWeb, proxies?
Click to expand...

Sorry to ask the obvious question. When you say you tested it on another account, did you physically move your computer to a new location, or are you using a laptop? It may still be something weird on your computer, if that's the common denominator. (It's also not entirely clear to me if another line or user has reproduced the problem).
 
Sabre - It seems something specific to you. Here's what I get (I was running an astraweb download at the same time)

Code: 
/home/debian $ wget -c http://feedproxy.google.com/~r/co/iEoF/~5/h4wfYLdJBFU/2nd.mp3
--2010-04-18 17:34:49--  http://feedproxy.google.com/~r/co/iEoF/~5/h4wfYLdJBFU/2nd.mp3
Resolving feedproxy.google.com... 66.102.13.118
Connecting to feedproxy.google.com|66.102.13.118|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.classicfm.co.za/talk/state-of-the-nation/podcasts/professors-lee-berger-and-paul-dirks-of-wits-chat-to-david-about-the-recent-fossil-discovery-that-may-shed-light-on-the-questions-who-are-we-and-where-do-we-come-from/podcast_download/2nd.mp3 [following]
--2010-04-18 17:34:49--  http://www.classicfm.co.za/talk/state-of-the-nation/podcasts/professors-lee-berger-and-paul-dirks-of-wits-chat-to-david-about-the-recent-fossil-discovery-that-may-shed-light-on-the-questions-who-are-we-and-where-do-we-come-from/podcast_download/2nd.mp3
Resolving www.classicfm.co.za... 41.203.2.60
Connecting to www.classicfm.co.za|41.203.2.60|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6420336 (6.1M) [audio/mpeg]
Saving to: “2nd.mp3”

100%[======================================================================>] 6,420,336    200K/s   in 31s

2010-04-18 17:35:20 (205 KB/s) - “2nd.mp3” saved [6420336/6420336]
 
Download Stalling: Summary to Date

Gordon_R said:
Sorry to ask the obvious question. When you say you tested it on another account, did you physically move your computer to a new location, or are you using a laptop? It may still be something weird on your computer, if that's the common denominator. (It's also not entirely clear to me if another line or user has reproduced the problem).
Click to expand...

  1. All equipment (computers, routers) has been restarted at least once.
  2. Port has been reset by MWeb Tech Support.
  3. All downloads when they ARE running, run at 38Kbps (384 account).
  4. Problem initially noticed on Wednesday 14 April 2010, using 'wget', but has been confirmed using Firefox on Ubuntu and Chrome on Vista. All further testing with 'wget'.
  5. Problematic files have been successfully downloaded over a separate wireless connection and at two other locations using capped 384 MWeb accounts.

Podcast mp3 file of 2.8MB succesfully downloaded via HTTP. Other files, 6.1MB and larger, over HTTP stall, do not finish and will not resume since 14 April 2010 on:

My line, my router, my account:
  • Desktop machine 1 running Ubuntu over ethernet connection
  • Desktop machine 2 running Ubuntu over ethernet connection
  • Laptop running Vista over wireless

My line, other router, other account (capped):
  • Desktop machine 2 running Ubuntu over ethernet connection
(Didn't test further as failure was demonstrated).

However:
3.9MB and 7.6MB files of random data for testing were SUCCESSFULLY downloaded over an SSH connection from local non-MWeb server.
7.6MB file SUCCESSFULLY downloaded over HTTP in a VPN.

Surely this implies some kind of throttling / interference from MWeb? If I can transfer 8MB over a VPN/SSH fine, but I can't even get 6.1MB over a normal HTTP connection, that HAS to mean MWeb or a proxy somewhere is interfering?
 
Last edited:
milomak said:
Sabre - It seems something specific to you. Here's what I get (I was running an astraweb download at the same time)

Code: 
/home/debian $ wget -c http://feedproxy.google.com/~r/co/iEoF/~5/h4wfYLdJBFU/2nd.mp3
--2010-04-18 17:34:49--  http://feedproxy.google.com/~r/co/iEoF/~5/h4wfYLdJBFU/2nd.mp3
Resolving feedproxy.google.com... 66.102.13.118
Connecting to feedproxy.google.com|66.102.13.118|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.classicfm.co.za/talk/state-of-the-nation/podcasts/professors-lee-berger-and-paul-dirks-of-wits-chat-to-david-about-the-recent-fossil-discovery-that-may-shed-light-on-the-questions-who-are-we-and-where-do-we-come-from/podcast_download/2nd.mp3 [following]
--2010-04-18 17:34:49--  http://www.classicfm.co.za/talk/state-of-the-nation/podcasts/professors-lee-berger-and-paul-dirks-of-wits-chat-to-david-about-the-recent-fossil-discovery-that-may-shed-light-on-the-questions-who-are-we-and-where-do-we-come-from/podcast_download/2nd.mp3
Resolving www.classicfm.co.za... 41.203.2.60
Connecting to www.classicfm.co.za|41.203.2.60|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6420336 (6.1M) [audio/mpeg]
Saving to: “2nd.mp3”

100%[======================================================================>] 6,420,336    200K/s   in 31s

2010-04-18 17:35:20 (205 KB/s) - “2nd.mp3” saved [6420336/6420336]
Click to expand...

Yeah, I have downloaded that and other files from locations of other MWeb users to check. See my previous post for details on the testing I have done -- it is occurring to me but is probably not related to any of my equipment.
 
SabreWolfy said:
Yeah, I have downloaded that and other files from locations of other MWeb users to check. See my previous post for details on the testing I have done -- it is occurring to me but is probably not related to any of my equipment.
Click to expand...

my point is that the problem is not what you say
Surely this implies some kind of throttling / interference from MWeb? If I can transfer 8MB over a VPN/SSH fine, but I can't even get 6.1MB over a normal HTTP connection, that HAS to mean MWeb or a proxy somewhere is interfering?
Click to expand...
 
Download Stalling

After being unable to pull down even 6.1MB file succesfully, I tried again, this time with an 18MB file. It downloaded to completion at 38Kbps. I then tried a 42MB. It stalled at 14MB and would not resume.

Thanks to everyone for their help and suggestions on this frustrating problem. I have no idea what the problem is; all I know is that's it's really driving me crazy.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X