Slow Speed 1.0 vs 0.5
Posted: Wed Oct 22, 2008 10:23 am
Hi Folks,
I know a few people have been complaining that the download speeds of the new version have been slower than the previous 0.5 releases and I'd like to try to clear some things up. Firstly, 1.0 shipped with no sane network defaults which caused a lot of routers to choke and connections to be saturated, this has been fixed and will continue to be tweaked going forward. We will also be working towards providing the configuration wizard once more to assist in finding proper settings for their connection.
The second reason for the difference, and something I don't believe has been discussed yet, is due to a change in libtorrent between the versions we use in 0.5 and 1.0 respectively. In the 0.5 series, the upload limit was only used to limit the payload data rate and did not account for protocol overhead where as the 1.0 series includes the protocol overhead in it's upload limit throttling. There is an inherit bandwidth overhead whenever you are sending or receiving packets on the internet, generally in the form of packet headers and ACKs, and since bittorrent utilizes many connections in operation, this overhead can become somewhat significant.
Now you are probably asking, what does all this mean and what do I need to do to improve my speeds? In a nutshell, by limiting the amount of protocol traffic, you are limiting your potential payload rate. So we just need to account for protocol traffic when we set our upload limits.
Example:
User has a line connection with a downstream limit of ~1.2MiB/s, but is only able to ever see ~300Kib/s when using Deluge 1.0. User has limited his upload speed to 10KiB/s, the same as he did when using 0.5.x. User is frustrated that downloading is going slow!
What the user did not account for is that the 10KiB/s limit now applies for protocol overhead too and it's typically in the range of 3-5% of your payload rate. So if we do the math, we'll see that User is using all of his allotted upload limit to send ACKs and other protocol overhead: 10 / 300 = 3.34%. As we can see, the download speed is being limited because there is no more upstream bandwidth available.
User has now realized his mistake and set this upload limit to ~4% of his maximum download speed, in this case about 50KiB/s, and is now enjoying full download speeds once again. User is no longer frustrated. Yay.
In conclusion, the problem in 0.5 was that libtorrent would only limit based on your payload rate and this could cause higher traffic than your chosen limit -- you can be using up to 30KiB/s (unreported by Deluge) upstream when downloading at 1MiB/s!. This problem has been solved in 1.0, but requires setting the upload limit a bit higher (you were always sending this much upstream, you just didn't see it).
Please remember that Deluge still only displays payload rates, so you will not see protocol traffic reported.
I hope this was informative and helps everyone get the most out of Deluge 1.0.
I know a few people have been complaining that the download speeds of the new version have been slower than the previous 0.5 releases and I'd like to try to clear some things up. Firstly, 1.0 shipped with no sane network defaults which caused a lot of routers to choke and connections to be saturated, this has been fixed and will continue to be tweaked going forward. We will also be working towards providing the configuration wizard once more to assist in finding proper settings for their connection.
The second reason for the difference, and something I don't believe has been discussed yet, is due to a change in libtorrent between the versions we use in 0.5 and 1.0 respectively. In the 0.5 series, the upload limit was only used to limit the payload data rate and did not account for protocol overhead where as the 1.0 series includes the protocol overhead in it's upload limit throttling. There is an inherit bandwidth overhead whenever you are sending or receiving packets on the internet, generally in the form of packet headers and ACKs, and since bittorrent utilizes many connections in operation, this overhead can become somewhat significant.
Now you are probably asking, what does all this mean and what do I need to do to improve my speeds? In a nutshell, by limiting the amount of protocol traffic, you are limiting your potential payload rate. So we just need to account for protocol traffic when we set our upload limits.
Example:
User has a line connection with a downstream limit of ~1.2MiB/s, but is only able to ever see ~300Kib/s when using Deluge 1.0. User has limited his upload speed to 10KiB/s, the same as he did when using 0.5.x. User is frustrated that downloading is going slow!
What the user did not account for is that the 10KiB/s limit now applies for protocol overhead too and it's typically in the range of 3-5% of your payload rate. So if we do the math, we'll see that User is using all of his allotted upload limit to send ACKs and other protocol overhead: 10 / 300 = 3.34%. As we can see, the download speed is being limited because there is no more upstream bandwidth available.
User has now realized his mistake and set this upload limit to ~4% of his maximum download speed, in this case about 50KiB/s, and is now enjoying full download speeds once again. User is no longer frustrated. Yay.
In conclusion, the problem in 0.5 was that libtorrent would only limit based on your payload rate and this could cause higher traffic than your chosen limit -- you can be using up to 30KiB/s (unreported by Deluge) upstream when downloading at 1MiB/s!. This problem has been solved in 1.0, but requires setting the upload limit a bit higher (you were always sending this much upstream, you just didn't see it).
Please remember that Deluge still only displays payload rates, so you will not see protocol traffic reported.
I hope this was informative and helps everyone get the most out of Deluge 1.0.