Problem Downloading

ok that stil doesn't explain why the stall happened on thread 6 and then later on thread 8, so now you're saying that my buffer on this one download app changed itself and the problem then accurs a good 8MB later.

Dude, no offence, not trying to be a **** but I just don't buy it
 
slimothy, I am not saying that it is kilobytes of data that is causing the problem! Could by just 4 byte sequence, or 8 bytes, or 16 or X, I have no idea, I altered quite a few KB as I was aware of the floating break point due to the buffering, so I wanted to make sure that I have removed anything from that area. One could have removed only 100 bytes at a time until the problem disapears so one can locate more precisely where the problem is.
 
so find the 4 byte sequence, mimmick it in other files and you may be able to argue your point, but untill then... its ludacris.

why not do this, copy the sequence you nulled out of that file, put it in a new file, upload to a few palces (free hosts, servers you have access to etc) and lets see if it breaks time and time again no matter where it is.
 
I think I will leave that task to you slimothy :-)

it is too complicated for me :-)
 
I have been capped now for ~1hr and it is working so well [from WBS' perspective] that I might be persuaded to purchase additional bandwidth - if I didn't have more self control and weren't already used to speedlessness. I can say that this capped throughput seems waaay better [need more time to form an opinion though] than the speedlessness of April, if only WBS had given me the speed to use up my cap so I could be on the speedy throttled link...:rolleyes:

In any case I regard WBS' website as being useless [I aint gonna be buying more bandwidth there] until they have SSL in place on all areas of the site that require logging-in as well as all areas once actually logged-in...:(
 
i dont think they need SSL unless its for the credit card bit, but ic you'd be stupid as hell to purchase bandwith now, 2 hours till i'm 1mbit again YEEEEEEEEEEEEEEEEHAAAAAAAAAAAWWWW

24 hours till i'm capped agin
meh :(
 
Trials & tribulations of being cr@pped...

I have been capped now for ~1hr and it is working so well [from WBS' perspective] that I might be persuaded to purchase additional bandwidth - if I didn't have more self control and weren't already used to speedlessness. I can say that this capped throughput seems waaay better [need more time to form an opinion though] than the speedlessness of April, if only WBS had given me the speed to use up my cap so I could be on the speedy throttled link...:rolleyes:

In any case I regard WBS' website as being useless [I aint gonna be buying more bandwidth there] until they have SSL in place on all areas of the site that require logging-in as well as all areas once actually logged-in...:(

Ohhhh goody this post just timed out - wonderful, I suppose it will end up being a semi-duplicate...soooo slow...especially http...
 
o goody delete it, and then delete this one too while you're at it, thx man
 
swordfish1 said:
I think I will leave that task to you slimothy :-)

it is too complicated for me :-)
Click to expand...

Nooooo! Please get to the bottom of this. Its intriguing. Both files in this thread also failed in Net Transport, and they are the only two failures I've ever had with NT.

The mountainblade file timedout on thread 6. I was getting 106KB/s until then.

I only got 4 threads with the W03 file. The 4th thread didn't even get off the mark. Total downloaded 809.4Kb.

Disconnecting/Reconnecting doesn't help.( IC, that is a signal problem you have for sure. )

I also fail to see how a particular combination of bytes would cause a stall, unless some app is inspecting the data... and for what? Its binary, any file could have any combination of data. :confused:

Some kind of Antivirus on the cache maybe???

Slim's suggestion would be quite easy to test, Sword. I would do it myself, but I don't have an original version of the file (not through lack of trying).
 
Last edited:
slimothy said:
2 hours till i'm 1mbit again
Click to expand...

Remember this is the first time that WBS will be resetting bandwidth. So do expect a fvck-up of some description...

Maybe it can only be reset during office hours. :D
 
jmn said:
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...
Click to expand...

The way to eliminate the server as a variable would be to add the original file to rapidshare as well. Then the only difference would be the files themselves.

Now, as to the paranoia expressed elsewhere that there is some difference in the file content, other than the nulled space, who cares? The fact of the matter is that if file content can trigger the stall, THAT is is the problem.

If anybody is using UUNET as an ISP on ADSL or leased line they could also try the problem file and it comes through OK there, then we are down to a problem in the WBS network. If the problem is reproducable there too, then we have a problem further upstream in that network.

Wherever or whatever the problem is, I would like to see it disappear. It has cost me a couple of hundred megabytes in retransmissions out of my cap.
 
Last edited:
slimothy said:
no the fact is we don't know if the content triggers the stall
Click to expand...

It is a working hypothesis that seems to fit the observed behaviour. If we use rapidshare for the problem file and it remains a problem file, we have probably ruled out the server. If you change the file and the problem goes away, that tends to indicate the file has a role to play in the problem. If you change your ISP and the problem goes away, that tends to indicate that the ISP has a role to play in the problem.

So, we seem to have a reproducible problem with a particular file and a particular ISP. What is your working hypothesis?
 
before we get to my workin hypothesis, lets get you to answer all my points in a previous post about how the packet shaper could not be responsible for this problem. If you know anything about firewalls, and intelligent firewalls (packet shapers) you will realise its insane to think this was caused by the one at WBS. But I'm willing to entertain the idea, because hey, I could be wrong here, so why don't you get what in IT we like to call a proof of concept. Just reproduce the problem under open conditions, copy the data that you say was responsible for the stall into a new file, just that data segment, nothing else, believe me it's easier that turning all those bytes into null bytes (which sword already did), then upload that file to multiple locations, and if it stalls again, hey presto we know a segment of data caused the stall.

Evidence is needed, if you can't do it or host the file, give the segment to me and i'll do it on multiple locations. Actually the proof would serve a second purpose because we could cut chunks off that segment and eventually find the exact byte sequence that you say causes the problem. We could then spread this info with certainty because we would all know its true. And if you'd care to address the following that'd help too:

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 talking about data packets as the connection can be made fine, it would shape it if the theory was true not drop it
 
slimothy said:
before we get to my workin hypothesis, lets get you to answer all my points in a previous post about how the packet shaper could not be responsible for this problem.
Click to expand...

Essentially you seem to be taking the position that file content is extremely unlikely to be causing the problem. Fair enough, but then I am puzzled by the following:

slimothy said:
without hash checks on pieces how do I know they are the same files with only a few bytes or kilobytes altered.
Click to expand...

If content is not at issue, why is this important?

slimothy said:
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.
Click to expand...

If you have a file that does not work and same file with a modification that does, it would seem to me that you have the material for experimentation to obtain more technical detail.

From where I sit you and swordfish seem to have gotten each others backs up. Reading on from http://www.mybroadband.co.za/vb/showpost.php?p=201014&postcount=36 things seem to have gone downhill, although the requested information was supplied.

Anyway, casting my eye back over the thread it would seem we have two articulated working hypotheses.

1. The content of certain files is causing a problem.

2. There are bad copies of the files in a caching server.

If uploading the problem file to rapidshare solves the problem, it would be an indicator in favour of the second. (Presumably the first download from a new server would put a new and intact copy in the cache.) The fact that the problem is not triggered by uploads certainly doesn't hurt the second, either.

So, swordfish, would you mind uploading the problem file to rapidshare, so we can undertake the next experiment?
 
[post=201093]
slimothy said:
o goody delete it, and then delete this one too while you're at it, thx man
Click to expand...
[/post]Why do you want me to delete your post - surely you can do that on your own? :p

About to disconnect, wait 5 minutes & see if I have another 3GB...:)
 
Well I am impressed - just logged into WBS' Bandwidth Monitor and it says I have 3GB remaining, well done Luis or whoever worked on the system :).

Now, about the file with the troublesome bytes thing - I might have given the wrong impression - I had problems with my own downloads stalling - not the file you've all been wasting bandwidth trying to download...;)

Added: Ooops that was a tad ambiguous, I forgot to mention that I never once wasted my precious bandwidth on trying to download the troublesome bytes file, hope that helps formulating all the hypothesis...
 
Last edited:
check the midnight! thread, and the other one, it hasn't updated for me yet but my speed is uncapped, which is all I care about
 
slimothy said:
check the midnight! thread, and the other one, it hasn't updated for me yet but my speed is uncapped, which is all I care about
Click to expand...
:confused: perhaps it's bcos I disconnected before midnight & then reconnected again just now...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X