Problem downloading large files

June 11, 2006 2:11 PM

I need help figuring out how to fix my home network.

I recently bought a new PC and set it up in a different location that previously. Since setting up the new machine I have been pretty much unable to download a file larger than a couple megs without it somehow ending up corrupted. For example, I just downloaded the latest video drivers from NVidia (21407 kb) six times and each time the self-extracting executable says that it is corrupted. I had a similar problem with the path for BF1942.

What can cause this kind of problem? I suspect line noise in the network. Because of the layout of the house, there is about 20 feet between the nearest phone jack and my computer. I currently have it set up with the DSL modem right by the jack with a very short phone line between the jack and the modem. Then a 30 ft. length of cat 5 between the modem and the router on my desk. Then a very short (3 ft I think) cat 5 from the router to my computer.

Right now the prime culprit is that 30ft length of cat 5. Its pretty old and has some creases and such in it.

What would you recomend to improve the situation? Is it possible to buy cat 5 with extra insulation or some such that is desinged to be run at lengths of 20-30 ft?

posted by Riemann to computers & internet (8 comments total)

As an addendum, do you know of any software that can be used to measure or test for noise over a network?
posted by Riemann at 2:31 PM on June 11, 2006

Another piece of the puzzle: I just logged in to the router base station for the first time in a while and it seems that for some reason the wireless security had been turned off and there was a list of 4 machines unknown to me in the DHCP directory.
posted by Riemann at 2:39 PM on June 11, 2006

You aren't getting anywhere near the distance limits of cat 5 cable - 100 meters. It is indeed that cable - probably in the ends or one of those kinks.

Go buy a new cable - you can go up to 300' with no loss of signal.
Regarding noise: your friend is the "ping" command.
posted by disclaimer at 2:52 PM on June 11, 2006

Riemann: I would first enable security immediately and test out the network with your machine being the only one on it.

Then, I would change all of your passwords on various websites, email accounts, etc.

One of the big culprits of the corruption could be someone running a network sniffer on your LAN, which causes boatloads of LAN traffic and can screw up your overall connection integrity if you don't have a high-end router that can handle that sort of a mess.

I don't mean to scare you, as your problem could be totally unrelated to the lack of security, too, but I'd err on the side of caution here. If fixing the security settings on your wireless solves your file corruption problem, it's safe to say the inflated traffic of all of your "borrowers" contributed to your issues.
posted by twiggy at 2:52 PM on June 11, 2006

Yeah, definitely look into the security thing.

But; when a network is over-utilized, the tendency will usually be to drop packets entirely at the routing points (since you're overrunning queues on the switch,) and not corrupt them. So, this seems like an unlikely cause.

More likely is that you in fact have a bum bit of hardware (for instance, the network cable you mentioned.) In TCP/IP, packets each contain a checksum code which is intended to prevent errors; coupled with the ethernet checksum, this should catch most errors, but this doesn't work 100% of the time.

If a segment of the network is introducing a massive number of bit errors, some teensy fraction of those could go undetected, which would account for the problems with large files.

One upshot is, when you fix the problem, you'll probably see improved network performance in general, since for every error that goes undetected, there are probably thousands of errors being detected by the network layer, and causing slowdown due to retransmits.

The correct procedure (once you've solved your security issues,) is to replace all parts of the network (cables, routers, network cards, computers,) one at a time (going from least to most expensive,) and see what fixes it. Obviously, this may be more or less practical, depending on how much access you have to things like spare network switches, cables, etc. But the cable is the obvious/cheap first thing to try. Good luck!
posted by blenderfish at 3:59 PM on June 11, 2006

As blenderfish said, any line noise or bad connections would cause either dropped packets or packets with an invalid CRC, both of which would result in a retransmission. TCP/IP was designed to handle this kind of thing, you know. So I wouldn't go blaming it on the network. Although it could very well be buggy network card *drivers*, or something like that.
posted by Rhomboid at 5:06 PM on June 11, 2006

You might try resetting the network link speed from auto or 100 to 10 and see it things clear up. This can be found in Control Panel, Network connections, (Select Network Card) Configue, Advanced Tab - Link Speed. Auto is really 100 MHz and this speed can cause corrupt files in bad wire. The link speed can also cause issues with some network cards, althought that is generally with equipment that is more than a couple of years old.
posted by ptm at 10:49 PM on June 11, 2006

TCP/IP was designed to handle this kind of thing, you know.

It isn't magic. TCP was designed to catch an occasional error, not crutch up a piece of broken equipment. TCP 'handles' errors by transmitting a 16-bit checksum of the data in the packet header. Which means that, roughly speaking, a random packet full of data entirely different than your original data has a 65,535 in 65,536 chance of being detected as incorrect, but a 1 in 65,536 chance of going undetected. In addition, the method used to calculate the checksum is fairly primitive (adding together all the 16-bit words,) so it is not going to, in practice, even be that effective at catching real line errors. So, we'll knock it down by a factor of 4, and give an error a 1 in 16,384 chance of going undetected. This is probably optimistic.

Since the typical packet size is about 1400 (Ethernet MTU [we'll optimistically ignore the length of the TCP/IP header itself],) if you are transferring a 21407000 byte video driver, and each packet has an error, that is 15,290 chances for TCP to screw up. Some quick math with the above probability of failure yields a 61% chance of at least one undetected error in the download. However, this is a simplified model, and may be optimistic, since each of the errors that _are_ detected will result in a retransmit, itself possibly containing an error that will go undetected.

So, TCP/IP is great at catching occasional errors, but is not going to be infallible in the long run.
posted by blenderfish at 1:27 AM on June 12, 2006