Problem Downloading

slimothy, do you really think I am sitting here writing stories ... !!!

tell me one good reason why I will be wasting my time doing that!
 
because you're bored, look I was giving you the benifit of the doubt untill you dodged questions, questions I asked because I'm curious and I'd like to know why it happens myself, if you overwrote at 807 - 812Kb, that means nothign to me, so far everyone can download that bit fine and that doesn't tell me the memory address of the bytes you claim to break the download, the problem with that is I can't take a look at it myself.
 
swordfish1 said:
ic, so you saying that reconnecting the modem and resuming the download works fine for you? That is new. I have not tried that.
Click to expand...
Yep, every 15 or 20 minutes the speed drops to zero 0.00000kbits/s on all threads and then I pause the download, goto the web interface for SWE2, drop the iBurst connection, reconnect & immediatedly resume the download which then reaches up to 90kBytes/s [for me]. There is nothing in my setup anywhere to kill the throughput like I see happening simultaneously on all threads from different mirrors (mixed local & international).
 
swordfish1 said:
The problematic spot for that particular file is about 807-808 KB (the file size is 1 MB). I overwrote the data on my local pc and I uplaoded the modified version to the external server.
Click to expand...

wget on my system stalls at 823,916 bytes for the file you have linked to. You could put your modified file up at http://www.rapidshare.de and provide the link on the forum.
 
yeah sword, why offer the problematic file somewhere else when we already know no matter where it is or what its called it will fail. Also the failing point of everyone's files and the point you overwrote don't match up.

I don't know if you were or weren't talking poopoo and I don't care, but I don't think we're any closer to finding out what causes the stall
 
slimothy said:
Also the failing point of everyone's files and the point you overwrote don't match up.
Click to expand...

Not true. My failure point came just after the 804K mark, which falls between the 800K and 812K overwritten by swordfish. (823,916/1,024 = 804.6K) Interestingly enough when I retried it, it failed at 828,960.

Coming back to the SuSE Linux 9.3 Live-DVD I have noticed two further failures at the 505,455,068 and 742,486,796 marks. In these cases, however, wget has been able to resume, albeit after having to make multiple resume attempts, restablish the ftp session three times in the first case, and restablish it twice in the second.
 
sorry my bad

lets talk in bytes then so, we (I) don't mess up

I overwrote approx from 820,000 to 831,000
 
OK, the version up at rapidshare downloads without any difficulties. Anything to add, slim?
 
so far we have proved that the problem occurs due to certain data sequence being transmitted.

I just look at the data in that area of the file (+/- 2000 bytes around 823,916) and it looks just like an archive, no text whatsoever, nothing looks out of order.
 
well slimothy, you have two files on the same server, the only difference is few thousand bytes being altered from whatever to 0x00, the one works fine, the other does not, hanging always on the same place.

Can you give another explanation, which does not involve the difference in the data?
 
1st time I tried it with Mozilla, it stopped at 804 kB, the 2nd time at 807 kB, the 3rd time at 803 kB, seems to be rather server related than file related...
(from original URL)

Now trying with dialup as well...
 
Last edited:
yes jmn, thats what puzzles me about all these posts, I'm not sure if its because people just want to say "hey look at me I was right woohoo you suck" or if they are just bored, but the lack of technical information means there isn't any real proof, and without hash checks on pieces how do I know they are the same files with only a few bytes or kilobytes altered.

Then with my own experience, it stalled on thread 6 (see previous post) but today it stalled on thread 8, I cleared and tried again and it stalled on thread 8 but about 100KB earlier than the first time.

I just think before we jump to conclusions with theories we need technical information as well as a theory that can account for why it stalls in different places at different times. more important to me than who's right and who's wrong is how accurate is the information.
 
also theres millions of combinations of bytes that you download, so I just don't understand this theory, are you guys saying that certain sequences of kilobytes causes downloads to stall because the packet shaping thinks its a bad packet and drops it?

couple problems with that theory
1) the sequence would have to be in bytes not kilobytes since packets are sent in bytes
2) the likley hood of you seeing that exact same combination of bytes anytime in your lifetime again are slim to non, we're talking about thousands of bytes.. so why does it happen with ic on his downloads, and mercury's suse download, I bet if you look for the same kilobyte sequence in those files they will not match up at all
3) packet shapers do not look at the data, they look at the frame, the constuction of the packet holding the data, so why would what the packet is carrying matter?
4) packet shapers, shape... not drop packets, they might drop connection packets if they're told to, but we're talkign abotu data packets as the connection can be made fine, it would shape it if the theory was truem not drop it

let me put it this way, if it is the packet shaper, I will chew off my left nut
 
Agreed...

I've found in the past that proxy servers, also transparent proxies, may affect downloads. I think WBS is using a transparent proxy. downloads may succeed if the proxy is bypassed.
 
i know they use a caching server, which is what I suspected since it acts liek a proxy, but even that I can't be sure on.

It worked for me on a modem, it worked also on ADSL, gprs failed at that point too (obviously i just resume the download i started with iburst and not download the whole thing with gprs)

i don't think anyone has an answer yet
 
slimothy, I am surprised you don't realise why it stalls once at 804 and other time at 807 or whatever! All programs that download files from internet use some sort of buffering, in some you can set it, in other you cannot and you don't know how big the buffer is.

Normally the program reads up to N bytest at a time where N is the size of the buffer. If it reads less than N for whatever reason, normally it will save the buffer regardless and will continue with the next chunk from empty buffer, but can be implemented differently. So the differences in the stoping points is due to the buffering.

See, I am not saying that the problem is iBurst necessarily, I am just saying that the problem is triggered by the data in the file, some data sequence is causing the download to hang irrespective of the server. So it is the data.

Now you can figure out if it is WBS problem or it is their internet provider problem, but it does not happen at my work (using optical link to IS), neither with my modem, so it is happening for now only when using iBurst.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X