top dl speed causes ul speed to drop

[lvm]

I've got 4M/768K link. Download speed is limited in deluge at 384K leaving some guaranteed bandwidth for web, etc, upload speed is not limited in deluge but QoS in a router gives outgoing torrent traffic no more than 80% of bandwidth and low priority, and I keep it simple - torrent traffic is defined as ports>1024. Now consider the following bandwidth usage chart:



Bandwidth usage is measured at the router's WAN interface - all traffic is accounted for, no other significant bandwidth users apart from deluge and myself. As you can see, there is a marked trend: as soon as dl speed (green) reaches its limit - mind it, not the physical link limit, but a limit set in deluge, ul speed (blue) sags, when dl speed drops, ul speed rebounds back to its maximum (I seed a lot, it always should be at maximum). To make sure that my ISP delivers the promised bandwidth and that there are no mistakes in my bandwidth calculation I'v started an ftp download - note the dl speed spike near the end of the chart, so there is indeed some free dl bandwidth left, and yet deluge struggles - why? Here http://forum.deluge-torrent.org/viewtop ... =7&t=11165 andar discusses why insufficient ul bandwidth can affect dl speed but what I see is an opposite - saturating dl bandwidth causes ul speed to drop. Possibly the cause is the same - ul protocol overhead competes with dl data and looses, but if it so - it is wrong, it means there is no way I can seed properly if I leech at top speed, priorities must be changed here. Of course I may be wrong an it is caused by something else.

1.1.3 linux x86_64, but seen on previous 1.x versions too.

[loki]

I've never used QoS on my router before, I always saw it as easier to set the program to limit upload/download.
I would venture a guess and say it was overloading the QoS if that's even possible.

[lvm]

Router CPU usage was hovering around 20% with no spikes. And by the way, neither it is caused by exceeding number of connections - both deluge connection count and router NAT table count were way below their maximums.

[jesperl]

To make sure that my ISP delivers the promised bandwidth and that there are no mistakes in my bandwidth calculation I'v started an ftp download - note the dl speed spike near the end of the chart, so there is indeed some free dl bandwidth left, and yet deluge struggles - why? Here http://forum.deluge-torrent.org/viewtop ... =7&t=11165 andar discusses why insufficient ul bandwidth can affect dl speed but what I see is an opposite - saturating dl bandwidth causes ul speed to drop. Possibly the cause is the same - ul protocol overhead competes with dl data and looses, but if it so - it is wrong, it means there is no way I can seed properly if I leech at top speed, priorities must be changed here. Of course I may be wrong an it is caused by something else.

When you are downloading, there are two types of upstream traffic: TCP ACK packets for the download and the regular uploads to your peers. Therefore, upload speed will drop when you are downloading, that's inevitable. Maybe your router is giving higher priority to the ACK packets than other upstream traffic? That would be a natural thing to do in a QoS implementation (I do it in mine..).

On the other hand, this shouldn't be a big deal on a 4096/768 connection since the speed asymmetry is quite small compared to most other ADSL connections (like my 20/2 which was a 20/1 until a month ago; when I max out on torrent downloads about 500 Kbit is used for ACK packets, IIRC).

By the way, depending on the QoS implementation in your router, you might want to set the TOS field in Deluge and let the router do QoS based on that. It's a lot more reliable than relying on port ranges. I guess that most applications will have source ports in the range you're using to identify torrent traffic (if it's a destination port range, you will classify IM MSN traffic as torrents).

[jesperl]

I've never used QoS on my router before, I always saw it as easier to set the program to limit upload/download.
I would venture a guess and say it was overloading the QoS if that's even possible.

Yeah, it easier, but...

In my opinion there's a huge difference between limiting torrent upload speed and doing proper QoS in the router. I can max out on torrent upload without slowing down web surfing at all, and latency (ping, traceroute) only increases by a few ms. This is on a 20/2 DSL connection.

Also, with QoS you can give higher priority to ACK packets so that your downloads finish faster on a well-seeded torrent. This is important on many DSL connections with a big speed asymmetry.

The only disadvantage of QoS is that you have to sacrifice about 10% of your upload speed. Otherwise upstream packets will queue up with your ISP, and your own traffic priorities will loose their effect. However, that still means that you can seed at 90% of max speed instead of 80% when you are doing the speed limiting in the Bittorrent client.