For any large download file I try to download from this PC, the download will stop in random places, rarely finishing the entire download. Even testmy.net's 5983KB download test size is too 'big', it usually stops right before 50%. For everything else, the progress percentage can stop at 3%, or maybe even 99%, its just random. Its getting annoying having to refresh then just stare at the progress bar/percentage hoping it makes it till the end; it is unneeded suspense.
I have Comcast HSI and the download problem doesn't exist on any of the other PCs..
Heres the layout of my LAN (made it one day when I was bored, never thought I'd use it :P ) www.mylilsite.net/images/networkmap1.jpg
Only the 'Tolchester' PC is having the above issue. Specs in sig. I use the motherboard's onboard gigabit ethernet, both ports suffer from the download issue. I tried connecting the PC directly to the D-Link DGL-4100 router and downloads still stop. This issue has existed through three reformats and BIOS versions 1009, 1103, 1205, 1303. At first version 1009 was flawless, the problem appeared later on with 1103 or 1205 (along with previously good OCs becoming unstable, but I would like to solve the download issue first). Then when I found out that 1103 and 1205 made the RAM unstable I flashed back to 1009 and the download issue still exists. Went from 1009 to 1303 and nothing that matters changed.
So.. yeah.. I really don't have any more ideas considering that the reformats did nothing.
This could be something you have already tried. Did you attempt a different port on the Linksys? I know you said it started after a bios upgrade/downgrade but. Could be coincidental? Maybe even try a different cable?
Last edited by Yeah; 08-16-2006 at 03:25 AM.
when i connected the PC directly to the D-Link DGL-4100, it was using the cable that used to be connected to the linksys... so thats a different cable and avoided the linksys..
Well, as you say it affects all downloads, it would appear the problem is your end and not the remote site(s). Looks like you've covered nearly all the hardware variations - different switch, cable etc. Do you have another nic you could through in that machine in case it's the onboard nic as that seems to be about the only possibility you haven't yet checked? What protocols are affected (ftp, http, tftp?), and what programs did you use to test?
After that, I'd suggest firing up a copy of ethereal and capturing some packets from a failed download and lets see if we can figure out from that where the problem may be.
One final thought - have you tried upgrading the firmware on the Linksys (I know you said you've tried it on the D-Link too, but it could still be a firmware issue). Also, are there any newer drivers available for your onboard nic you could try.
ill try a PCI NIC soon, after i check if i can update the onboard nic drivers. The download stops the same way for FTP, I've used IE, Firefox, SmartFTP, and FileZilla, didn't try anything else. I guess I'll mention that I have no issues with transfers to and from other PCs on the network.
I'm hesitant on upgrading the firmware on the linksys, it uses an old version (1.45.7) because the newer versions simply dont work with counter-strike, stupid linksys.
ok just tried with a Netgear FA311 v.1, download still stopped when i did a testmy.net 5983KB test (stopped at 81%) i captured the packets with ethereal: http://www.mylilsite.net/ethereal1.cap
it looks to have captured something useful near the bottom (end), but im not sure what it means..
Your packet capture is basically showing that packet segments are getting lost in transmission (starts around frame 4825 - 4917, and again at frame 6998). The server is resending them, but after a while it gives up waiting for a response that they've been received. If you take a look at frame 7086, this is where the download really starts to die. It's retransmitted again in in frames 7088, 7092, 7094, 7098, 7105 and 7112, and each time the delay increases from 200ms, 761ms, 1.88s, 4.1s, 8.6s to finally 17.5 seconds where the capture was terminated. At this point the server is giving up on repeatedly sending the packet and not receiving a response that the packet has been received, and is just increasing the resend time for the packet until it receives a response.