• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Dowloading vs. Uploading

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

dreamtfk

Member
Joined
Feb 1, 2002
Location
Orlando FL
Why does my connection slow to a crawl when I am uploading data but when I am downloading several files I can still surf the internet?
 
Cause you have an asynchronous connection: your pipe for downloading is bigger than for uploading.
Every datapacket needs to send an acknowledgement back to the sender to ensure the transmssion was without error. This ACK packet is a lot smaller than the datapacket (usually 8 bytes or so vs. the 1500 of the data packet). When you download something the upstream channel for this ACK packet is free and it uploads fast, you can still surf the web. If you upload something, that upload channel is already totally full and those ACK packets you generate by surfing have to be put into a queue and wait for a time. Sometimes up to several seconds. The webserver you surf however can't send the next datapacket down unless you acknowledge the last one with your ack packet. So it takes a lot of time for every 1500 byte packet to get through from that webserver
 
In general, a TCP/IP Transfer, it goes like this:
Client > Server: Hi (SYN)
Server > Client: Hi (SYN, ACK)
Client > Server: Nice to meet you (SYN, ACK)
Client > Server: Gimmie parts 1-3 of file XYZ
Server > Client: [DATA 1]
Server > Client: [DATA 2]
Server > Client: [DATA 3]
Client > Server: OK, I got those fine (ACK), Gimme parts 4-6
...

This is done so that if any part along the way is dropped or corrupted, instead of returning ACK, the client just asks for the missing pieces. This is true for any kind of TCP transfer... downloading of webpages, images, FTP, etc.

TCP Windowing will stretch this as much as possible, so stable transfers do not require the client to ACK as often, speeding it up, but unstable transfers require a lot more ACKing.

Now look at the timeframe, the server can transmit parts 1-3 very quickly, but then has to wait for the ACK from the client. Depending on the latency of your connection, you may be 50ms or 800ms away from the server, so it may take a while (like 1.6 seconds in the 800ms example) for the ACK to get back to the server to continue loading the webpage.

Since cable and DSL have such a restricted upload pipe, data is transferred slower in upload, so, if you have a 768kilobit upload, then you can only transfer 96 kilobytes per second. Now, in a normal network, it's FIFO (first in, first out) queueing for upload, so since your network is high-speed 100MBit, your computer has no problem transmitting a bunch of upload packets, but when they get to your modem, it can only send them so fast, so the modem will build a queue of packets to send... if you then return an ACK, it will be placed behind the upload packets in queue... if the queue has 200kilobytes in it, then the ACK has to wait an additional 2 seconds before it's actually transmitted.

To speed it up, you can implement traffic shaping, which, when properly configured, will keep the queue on your router or firewall (instead of on your modem), and when a high-priority packet comes through, like an ACK, it can jump to the front of the queue. Another way is to restrict uploading so that it doesn't fill your upload cap, leaving room for ACKs and other traffic.

DNS requests, although not TCP traffic, will also get hit by this... when you first request a webpage, you may need to do a DNS lookup, before even connecting to the server (when your browser says, "Looking up hostname XYZ.com...", or similar), if your upload queue is a constant 500ms wait, then counting only the queueing time on your modem, it'll take 500ms to send the DNS request, then 1 second for the TCP handshake, so essentially, 1.5 seconds before you even request what you want.
 
Back