Problem Downloading

[Rath]

Can anyone on iBurst download this file:

http://mountandblade.com/download/mountandblade_0623_setup.exe

It's supposedly a really fun RPG that's in development, a 34mb download. I just cannot seem to get past the 54% mark. It just keeps stalling. Even when I run download manager software, I can get every part of the file except the bit between 54% and 55%. I've tried GetRight, native downloading in Firefox and in IE - all do the same thing.

I've tried getting it from 3 different servers now, and they all do the same thing. On one of the servers the file is slightly different (old version) and that one also stalls at about the same place.

Too weird. Anyone have any ideas as to why this is happening?

[slimothy]

I tried to get it. I watched carefully as it crept around the 54% mark but it was fine... untill it got to 94% and then it stalled. I used a download manager with 10 threads and thread 6 died and only seemed to download 1.49MB compared to the 3.44MB of the other 9. Thats a real weird problem you have there. I tried resuming but it just sat there, didn't move an inch

[Rath]

I used GR to run 4 threads, and it's the third thread that dies while trying to retrieve a piece from around the middle of the file.

You are the second person I know of now who has stalled on that file. Everyone else is fine, and I'm talking about a pool of people that's easily over 250. You ran 10 threads... and thread 6 died, I bet we stalled on the same spot.

What the hell... *ponder*

[Darke]

99%, one block remaining and it hung on thread 3 in Download express. One data block left.. Pausing and resuming didn't help. :confused:

[nocilah]

also tried and the third thread died. i have had that before... use google to find another place to download it. i think the file is either corrupt in that one spot or it just dislikes us all... only got to 97%

[swordfish1]

I had exactly the same problem downloading a file from http couple of days ago. Very different file than the one above! Mine did stop around 2.8 MB. Also the site I was downloading from was offering the same thing broken into pieces of 1 MB each (for dial-up users, they say). I tried downloading that version and it stop on the 3rd piece about after 0.8 MB, so exactly the same place. So I assume there are certain data sequences that confuse the inferior iBurst packet filtering crap.

I wonder if they ever going to do something right!

PS: forgot to say, that I downloaded the file at the same time over a dial-up modem, so it was not the server I was downloading from, it is iBurst! What a surprise!

[slimothy]

can we get someone not on iburst to confirm this specific file can be downloaded.

[swordfish1]

it is too big, otherwise I would have tried on my modem connection

can try from work on Tuesday if there is no one else willing to do it sooner

[slimothy]

just tried on one of my servers


[root@smythinc root]# wget http://mountandblade.com/download/mountandblade_0623_setup.exe
--17:50:28-- http://mountandblade.com/download/mountandblade_0623_setup.exe
=> `mountandblade_0623_setup.exe'
Resolving mountandblade.com... done.
Connecting to mountandblade.com[72.22.64.119]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 36,074,602 [application/octet-stream]

100%[================================================== ====>] 36,074,602 968.74K/s ETA 00:00

17:51:04 (968.74 KB/s) - `mountandblade_0623_setup.exe' saved [36074602/36074602]

[Rath]

I am supremely confident that the reason I cannot get this file has nothing to do with the server hosting the file, nor with the file itself.

The following file is different, and is apparently hosted on a different server - yet I get a similar problem trying to get it down:

http://st39.startlogic.com/~mountand/mountandblade_0622_setup.exe

[slimothy]

yes we established that when I downloaded it on my server, the problem may or may not be with iBurst, it could be on the network which iBurst uses or it could be on the iBurst network itself. But none of that matters to you I'm sure, you just want the file

[swordfish1]

So I wonder how many files are there hosted on HTTP servers, which iBursters cannot download ... and now we are talking about completely legitimate stuff, not p2p, so what is the iBurst excuse now?! For 10 years using internet I never had such problem, files that cannot be downloaded due to hanging somewhere in the middle :-)

Well done WBS! Keep the crap going.

[Mercury]

So much for my downloading the SuSE Linux 9.3 Live-DVD. The downloads consistently stall at that 39.9MB mark. Mozilla download manager or KGet, Georgia or California servers. One nice thing is that I get 80 - 120 kBs up to that point...

[nocilah]

one thing i have noticed is in both cases it has been with .exe files... weird.. maybe unrelated... but something worth while investigating?

[Mercury]

The Live-DVD is an ISO file.

[nocilah]

yeah was reffering to the exe on this forum and an exe i had similiar trouble with..

[Nickste]

http://www.silenceisdefeat.org/~nickste/

try get it from here... I can rename file type as well if you want?

Chow, Nick

[Rath]

Thanks for trying Nick, still get the same problem on my side though.

[Mercury]

So much for my downloading the SuSE Linux 9.3 Live-DVD. The downloads consistently stall at that 39.9MB mark. Mozilla download manager or KGet, Georgia or California servers. One nice thing is that I get 80 - 120 kBs up to that point...

OK, my workaround was to use my dial-up connection to download the next megabyte of the file. Stop the download, restart it using iBurst, and I am back on the road again. :) Let us see if there is another point where it stalls.

For any WBS people reading this post, please bear in mind my problem occurred using FTP, a protocol you explicity support on all your packages. :(

[swordfish1]

Mercury, I had the same problem with HTTP, and they even more officially support HTTP, so this does not matter. I see that problems from this sort become more and more common, I wonder what will be their excuse for that ... Probably you have your windows closed and the signal couldn't get through :-)

[slimothy]

i don't think WBS is blocking file types or you wouldn't be able to start the download in the first place, you'd just send the request and no data would return. I'm trying to think where a problem could lie... and I think it must be the caching servers. I am downloading SuSe 9.3 eval DVD ISO righ tnow as it happens, I am 1.4GB through and haven't had a problem yet.. but then again I did chuck about 8 mirrors into my download manager

[swordfish1]

slimothy, I think the problem is in their useless packet management system. I had the same problem, and my conclusion is that the problem is caused by some data sequence in the data transmitted. It seems that their crap system is misinterpreting the data or something so it drops that packet, so it never continues. As you can see it depends on the file downloaded, no matter where the file is coming from or what type it is.

It is one of those things that WBS did not do intentionally, it just happened due to their incompetence.

[slimothy]

what packet management? if you are refering to the packet shaping, there are absolutley no rules for http, also if it was a dropped packet you request it again but I notice that the request stop and the thing just dies, I think we need to look for evidence before we can categorically state what the problem is... could be anything, for all we know its a problem with WBS' provider and not WBS.

Here's what we know for certain, its not a problem with the server so the problem lies somewhere between the server and us, could be WBS, probably is WBS but we can't be certain yet.

[swordfish1]

can we get one of those problematic files and wipe out (fill with zeroes) the part that causes the connection to hang, then put it on some external server and see if it works. So this way we can figure out if the problem is triggered by a data sequence in the file, which is my theory.

Actually I can do that test ... just will take me a while

[slimothy]

overwriting data with nullbytes won't work either. If you did it and downloaded the file fine any reasonable person would just say, but you didn't download it fromt he same server. I see where you're going with this, you think that at that portion (actually for me the place it stalls changed) there is some data that when sent in the packet gets caught by the packet manager and causes it to stall, that idea isn't out there, and sounds sorta feasable, but if you know packet shaping software (intelligent firewalls) you will know that rather than creating 256K or more memory space checkign each and every packet sent, which is dumb because the packet manager will end up wasting resources on junk packets that don't help ot do its job, they rather grab and check the packets that are responsible for creatign and maintaining the connection, they look at packet structure as well as type of data sent and of course source port, destination port etc etc. That way they only read packets that help it do its job. So if the stall was due to the packet shaping then it would not create the connection or throttle it all the way through, not stall.

But, we all know WBS isn't above making a hiccup or two, so maybe there is something in that specific packet that gets dropped because of thier shaping rules (but again, why would they drop it and not throttle it, as far as I know WBS don't have policies to BLOCK traffic, just shape it)... but I'm sticking with the cache server thing for now.

Can someone run a packet sniffer when downloading that area of the file and paste the packets for us to see?

[ic]

I have a different opinion - I still have ~350MB left so I am not yet capped, and my multi-threaded & multi-mirror downloads seem to stall every 15..20 minutes, the only way around it is to pause the download (only running 1 at a time now) then drop the iBurst connection in SWE2, reconnect and then resume as soon as SWE2 beeps to say the connection is re-established...:(

[swordfish1]

My theory proven!

I just replaced 10 KB of data with zeroes in one of the problematic files without changing the files size, name etc at all, and the file now can be downloaded just fine.

Note as well that the problem does not occur on upload! So you can upload problematic file just fine.

[swordfish1]

sorry for the incompetence, but what is SWE2?

[slimothy]

what do you mean zero's? null bytes or ascii zero's (as in the letter 0), also how did you download the file, and where did you place the zeros, what addresses? also can you paste a link so we can try download it too.

[swordfish1]

null bytes, not letter '0', but I guess either way will work

[slimothy]

yeah so where did you place them, where did you upload the file, and how did you download it

[ic]

sorry for the incompetence, but what is SWE2?SmoothWall Express V2 (http://smoothwall.org/)

[swordfish1]

I uploaded and downloaded via FTP

1. I have a copy of the file on my local machine downloaded via modem some time ago
2. I uploaded that exact copy to a web site to which I have FTP access
3. I attempted to download the file via FTP just after the upload finished, and it stuck at the exact same place where it did originally.
4. I modified my local file (copy of it of course), replacing couple of KB around the problematic spot with 0x00 bytes
5. I upload the new file to the same web site (renamed the previously uploaded file, so the modified one remain with its original name)
6. I downloaded the file via FTP and it got through just fine.

So you have 2 files on the same server, with only difference being couple of KB wiped out with 0x00 in the one of them, and the one works, the other doesn't ...

[swordfish1]

ic, so you saying that reconnecting the modem and resuming the download works fine for you? That is new. I have not tried that.

[swordfish1]

I see there are some Linux people here, so I am going to post a new thread with some questions I have about the UTD on linux ... please have a look in 5 minutes and any help will be appreciated

[slimothy]

dude this is starting to sound like bullsh*t, ok clear this up for me real quick, WHERE did you overwrite the data, where is this "problematic spot" because I want to try, or did you just pick random places, because that wouldn't make sense, WHERE is the link to the copy you uploaded, or are we just supposed to take your word for it.

[swordfish1]

unfortunatelly if I post the link to the file this will reveal my real identity :-) hence the reason for not posting the link on the forum ...

[slimothy]

yeah, sure, whatever, so how about answering the other questions, because this sounds like a story, where in the file did you overwrite data, and what did you use to overwrite it

[swordfish1]

slimothy, I can upload the files to place of your choice ... just tell me where

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.

this is the original link to the problematic file
http://www.fxcorporate.com/FXCM/tsmulti/FXTSInstall.W03

[swordfish1]

I overwrote the file between 800 and 812 KB approximatelly, and used UltraEdit in hex mode for that and my finger on the 0 key for few minutes, please save your comments how dumb I am doing it in such a manual way ... I am sure there is a nice cryptic command line on linux that will do it for a blink of an eye, but I don't know it.

[swordfish1]

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!

[slimothy]

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.

[ic]

ic, so you saying that reconnecting the modem and resuming the download works fine for you? That is new. I have not tried that.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).

[Mercury]

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.

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.

[slimothy]

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

[swordfish1]

what does not match up slim ????

[Mercury]

Also the failing point of everyone's files and the point you overwrote don't match up.

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.

[swordfish1]

sorry my bad

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

I overwrote approx from 820,000 to 831,000

[swordfish1]

I just did the upload, here you go

http://rapidshare.de/files/1508463/FXTSInstall.W03.html

this is the file with 0x00 between 820,000 and 831,000 approximatelly, check it yourself, otherwise is exactly the same file

[Mercury]

OK, the version up at rapidshare downloads without any difficulties. Anything to add, slim?

[swordfish1]

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.

[slimothy]

i don't think that constitutes as proof, but thats just me

[swordfish1]

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?

[jmn]

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...

[slimothy]

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.

[jmn]

OK, dialup worked...

[slimothy]

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

[jmn]

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.

[slimothy]

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

[swordfish1]

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.

[slimothy]

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

[swordfish1]

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.

[slimothy]

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.

[swordfish1]

I think I will leave that task to you slimothy :-)

it is too complicated for me :-)

[ic]

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...:(

[slimothy]

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 :(

[ic]

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...

[slimothy]

o goody delete it, and then delete this one too while you're at it, thx man

[Gatecrasher]

I think I will leave that task to you slimothy :-)

it is too complicated for me :-)

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).

[Gatecrasher]

2 hours till i'm 1mbit again

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

[Mercury]

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...

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.

[slimothy]

no the fact is we don't know if the content triggers the stall

[Mercury]

no the fact is we don't know if the content triggers the stall

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?

[slimothy]

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

[Mercury]

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.

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:


without hash checks on pieces how do I know they are the same files with only a few bytes or kilobytes altered.

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


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.

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?

[ic]

o goody delete it, and then delete this one too while you're at it, thx manWhy 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...:)

[ic]

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...

[slimothy]

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

[ic]

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:confused: perhaps it's bcos I disconnected before midnight & then reconnected again just now...

[slimothy]

i did the same :(

[seburn]

try go to eve.rau.ac.za I can't give out user or pass
but just see how slow it runs i get .3kbytes/s down
but 5kb when using dialup
don't ping the site (pointless)

[ScrnScrm]

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

Hey Slim
That actually depends on what QoS device they are using. If the shaper is doing stateful packet inspection on Layer 7 of the stack, it will look at the contents of the frame. The newer devices like the Perebit stuff assign hash values to bit sequences within a frame. That is how they accomplish their "Impressive" compression. If the file has already been compressed, it sometimes gets itself into a not with the hash values. I have seen this problem before plenty of times on QoS Devices. The only way to fix it is to flush the cache on the device (both sides) and let it rebuild. I cant even begin to tell you how frustrating this is when trying to troubleshoot SAP R/3 connections over compression devices :D
Ciao