does uploading slow down downloading

[nicksinif]

lets say my upload limit is 30k/s and my download is 300k/s. if i am using 25k upload, will that affect the download speed of 300? or are they unrelated?

 

[MrGuvernment]

with a good ISP, no, it shouldnt, but i have seen some

example

My works T1 - i can download at 180ish KB on a good day, that is also while having 2 things uploading at around 50KB each and they stay steady.


But, my cable ISP, if i download and upload (2mb down / 256kb up) it slows the other down.

 

[Malk-a-mite]

lets say my upload limit is 30k/s and my download is 300k/s. if i am using 25k upload, will that affect the download speed of 300? or are they unrelated?

Ummm - [looks above] - errrr....

They are related. Everytime* you make a connection online you are sending and recieving information. When you view a web page, you make a request to see the information, the server sends it and you reply that you got the information.

If you are using up large amounts of your upload bandwidth serveing information to other systems it can have an effect on your available download speed.


*ok so it's not everytime but I didn't think we needed that much detail for this

 

[Asian Dub Foundation]

never use more than 90 percent of your upload bandwidth to be safe, its what those guides about downloading and uploading torrents says anyways

 

[Xipher]

Depends on weather the medium and hardware can support half or full duplex.

 

[placeboFx]

I would also say that you should avoid uploading a lot of data while downloading.

 

[Stellar]

Theoretically speaking they shouldn't interfere with one another... they are physically separate (2 send wires, 2 receive wires), but the fact that there is software overhead involved at both ends above the network layer when you have multiple connections adds a bit to latency both ways.

 

[Ezekial]

while technically if isn't supposed too...

it normally does for me. Especially with torrents because there is just so freaking many connections it makes.
So I normally make my upload around half of my total. Normally I send out around 80kbs but I lock my torrents in around 40 to keep my speeds comfortable.
Grated I could go higher... but during busy times of hte night, my upload is often reduced and my interent connection gets slower.

 

[movax]

Theoretically speaking they shouldn't interfere with one another... they are physically separate (2 send wires, 2 receive wires),

Uh, what? Last I looked, coax doesn't have 4 wires.

@OP: Setup QoS to limit upload for P2P and other stuff to around 90, 85% of your max upload speed. That way, ACK packets always have a chance to make it out relative unhindered. You notice a slowdown because you've saturated your upstream, slowing down the ACKs responding to the SYNs.

 

[Stellar]

Uh, what? Last I looked, coax doesn't have 4 wires.

@OP: Setup QoS to limit upload for P2P and other stuff to around 90, 85% of your max upload speed. That way, ACK packets always have a chance to make it out relative unhindered. You notice a slowdown because you've saturated your upstream, slowing down the ACKs responding to the SYNs.

Who said anything about coax?

 

[da sponge]

Theoretically speaking they shouldn't interfere with one another... they are physically separate (2 send wires, 2 receive wires), but the fact that there is software overhead involved at both ends above the network layer when you have multiple connections adds a bit to latency both ways.

False.

The reason your downloads slow down when you're saturating your upstream bandwidth is that for each packet you receive you need to send an ACK back before you get sent another packet. If your upload is saturated, that ACK will get delayed/discarded. You won't get the next packet until the sender receives that ACK.

I'm no TCP expert, but I think the general idea is correct.

 

[Xipher]

Theoretically speaking they shouldn't interfere with one another... they are physically separate (2 send wires, 2 receive wires), but the fact that there is software overhead involved at both ends above the network layer when you have multiple connections adds a bit to latency both ways.
second post
Who said anything about coax?

The original poster never said what kind of connection he is talking about. This could be DSL, or cable (could be something else but those are my best guesses)

Coax uses 2 different frequency ranges, 1 for down and 1 for up, I don't know if they are full duplex or not though.

I don't know much about the technical side of DSL, so some one else might be able to comment on that.

False.

The reason your downloads slow down when you're saturating your upstream bandwidth is that for each packet you receive you need to send an ACK back before you get sent another packet. If your upload is saturated, that ACK will get delayed/discarded. You won't get the next packet until the sender receives that ACK.

I'm no TCP expert, but I think the general idea is correct.

Your a bit off, TCP will send multiple packets before it waits on an ACK, thats dynamicly adjusted up and down based on how well things repsond, its known as the sliding window.

 

[Stellar]

False.

The reason your downloads slow down when you're saturating your upstream bandwidth is that for each packet you receive you need to send an ACK back before you get sent another packet. If your upload is saturated, that ACK will get delayed/discarded. You won't get the next packet until the sender receives that ACK.

I'm no TCP expert, but I think the general idea is correct.

"False"

You just restated what I stated. (i.e. "overhead" both ways, multiple connections), only you were more specific.

 

[da sponge]

"False"

You just restated what I stated. (i.e. "overhead" both ways, multiple connections), only you were more specific.

I guess I was coming from the position that it wasn't software overhead that mysteriously adds latency. It was the saturation of upstream bandwidth that crowds out important ack packets that causes a reduction in download speed. This could happen with one connection maxing your upload (an FTP server or IRC fserv).

 

[goodcooper]

can't have packs without acks... it is as simple as that...

having dedicated wires for sending and recieving has nothing to do with it...

perfect example... go download a popular torrent... and let your torrent app have all the upload bandwidth it wants...


then try to go download your newest nvidia drivers... or shoot, just try to browse the web...


case and point, it is just how TCP works...

now UDP on the other hand... the only reason your counterstrike source lags when you're uploading a lot is because your position isn't being updated to the server as quickly as you are downloading all of your enemies position... to make the game fair (as fair as possible... some people 'hack' this way), you lag...

 

[Xipher]

can't have packs without acks... it is as simple as that...

TCP uses ACK, UDP does not. I believe BT does use TCP though. Thing is an ACK packet is tiny, and pretty insignificant compared to uploading data (like when your seeding to others). I read the rest of your post, but I wanted to make sure some one didn't get confused by this statement.

 

[Ur_Mom]

A T1, which is syncronious, can do both at the same time.

DSL/Cable, Dial up are asyncronious. They can only send or recieve. They can only do one.

For the most part (half/full duplex).

This may be old or even wrong, as I haven't looked into it for a while.

 

[goodcooper]

A T1, which is syncronious, can do both at the same time.

DSL/Cable, Dial up are asyncronious. They can only send or recieve. They can only do one.

For the most part (half/full duplex).

This may be old or even wrong, as I haven't looked into it for a while.

i guess i can't say that this is wrong, just that it makes no difference, has nothing to do with the OP's request...

syncronous just means it has the same speed upload as download... T1 is a ~1.5mbps syncro connection, it has ~1.5mbps download as well as upload speeds... DSL and cable can be purchased in synchro packages (but will cost considerably more)

TCP uses ACK, UDP does not. I believe BT does use TCP though. Thing is an ACK packet is tiny, and pretty insignificant compared to uploading data (like when your seeding to others). I read the rest of your post, but I wanted to make sure some one didn't get confused by this statement.

i used the example of UDP vs TCP thinking it would be a good illustration, which is dumb, because there is no gaurantee that you know what the differences are

yes, maybe i should have went into greater detail... UDP is a connectionless suite... which means it does not require an acknowledgement of reciept... anotherwords, if you are recieving some UDP packets and one gets dropped, the computer who is sending doesn't care if it is lost and WILL not resend (it doesn't even know it has lost a packet)...

TCP works on an acknowledgement basis, if things (data) need to be sent sans corruption and in the right order, the server needs to know if it needs to resend a packet if [when] one is lost (and the client needs to know in which order it needs to put the data that was dropped, because since then it has recieved other packets), BT most certainly uses TCP, as does HTTP, and the vast vast majority of P2P apps (all of the traffic the OP is referring to), lol does anyone use TFTP as a p2p medium?


basically, in summary, as far as important internet traffic is concerned, upload most certainly affects download, and the answer to your problems is to divide your traffic into ports (i.e., knowing what the ports are) and set up some QoS rules

 

[Malk-a-mite]

I think we've reached the point with this where you all decide to start quoting RFCs or we let this one slip quietly off the main page.