Uploading more than halfs download speed *WHY*

flames247 · 26-09-2004, 09:45

I'v always wonderd, Why the hell is it that when your uploading at say 30 Kb/sec it completely STUFFS for your download speed?

It's so bloody anoying, is there anyway you can sort this out or is this just the nature of cable?

I'm on the 1.5 service.

-Flames

paulyoung666 · 26-09-2004, 10:12

hi and

to the site , it is the nature of the system , i dont know why i just know it is

, enjoy your stay here

**Paul M** · 26-09-2004, 11:20

Quote:

Originally Posted by flames247

I'v always wonderd, Why the hell is it that when your uploading at say 30 Kb/sec it completely STUFFS for your download speed?

It's so bloody anoying, is there anyway you can sort this out or is this just the nature of cable?

I'm on the 1.5 service.

-Flames

It's nothing to do with cable as such, it is to do with how TCP/IP works.

Basically on systems with different upload/download speeds, as you approch you maximum upload speed, the download will slow down drastically to match.

BBKing · 26-09-2004, 11:23

It's the nature of TCP, I'm afraid, feel free to write your own control protocol.

To cut a long and boring story short, when you're transferring data in one direction it always sends some data back in the other direction. This happens on cable, DSL, Ethernet or any other medium that supports TCP/IP. This data takes capacity from the total available in the opposite direction.

SMHarman · 26-09-2004, 12:41

BBKing has already explained well but here is more. Say you want to download a 10 k file, this will be sent as say 10 1k IP packets numbered 1-10, they can come any route across the internet from the host to your PC, some may get lost, so each time you get one of these 1k packets, your computer sends a small message back to the host server sayinig it recieved that packet. The host will then resend the ones it has not had that message back for.

So downloading requires some upload bandwith, using upload to its max will mean that these ACKnowledgement packets will not be sent timely and so the host will be waiting for them before sending more.

Ignition · 26-09-2004, 13:40

Only thing you can do to mitigate this is cap the P2P client / FTP upload bandwidth really.

punky · 26-09-2004, 17:34

There might be something wrong with your connection. Downloads influence uploads, and visa versa, but the difference is neglible. If the packets are 1k, then the check bits would be just that - bits. 1/8th or less of your transfer. When i'm downloading at 125k/s, which is full wack on my line, the upload never really hits 3k, and when i'm upping at 30k/s, the downloads rarely hit 1k/s (going by DU Meter). When i'm uploading, and I download somethig, I didn't noticed an almighty great shift in speed for my upload, and visa versa.

BBKing · 26-09-2004, 20:45

It's not so much the size of the acks, but any delay to them that has a serious effect on the data connection. While the far end is waiting for an ack, the throughput is effectively zero. As Ig says, throttle any high-usage upstream applications if you want to see downloads near maximum while using upstream - it's what I do (and Ig, when downloading his donkey-and-nun videos).

Matth · 27-09-2004, 23:12

If you cannot restrict the upload in the software, the only other solution is to try brute force - a larger than normal RWIN, treating the link as if it is a severely delayed link - you MUST also have selective ACK enabled, especially with a large RWIN.

http://www.dslreports.com/drtcp

Selective ack, default is ON
Max duplicate acks, default is 3 for Win98/ME, 2 for 2k/XP - under these conditions, 3 may be better.

If you are uploading at 30k (256kbit) and downloading at 1.5 Mbit, then an attemped RWIN balance would be 6x the expected RWIN set by the other end of the upload - assuming 8760, you would use at least 52560 - actually the NTL Setup may have raised it already.