This forum has been archived. All content is frozen. Please use KDE Discuss instead.

svn 50KB upload cap on 512 capable line cuts down speed

Tags: None
(comma "," separated)
Nick_13ro
Registered Member
Posts
75
Karma
0
Using latest svn and a 50KB upload limit on a 512 cap cable connection which should do 64 severely limits download speed. I tested that by starting a ftp download too. I had to bring down the limit to 42KB (the upload speed reported seems to always be 1 kb higher than the limit btw). I used to be able to use a 50KB limit without problems :?.
George
Moderator
Posts
5421
Karma
1

Sat Jun 02, 2007 10:58 am
We haven't made many changes in those parts of the code lately.
Nick_13ro
Registered Member
Posts
75
Karma
0

Sat Jun 02, 2007 11:07 am
George wrote:We haven't made many changes in those parts of the code lately.


Maybe it's my ISP then :| anyway it was happening with an older svn too, 2 weeks old.
clayne
Registered Member
Posts
16
Karma
0

Sat Jun 02, 2007 4:27 pm
This is fairly typical. I also have a 512kB up limit and anything over 42kBps will dig into a download.

Methods to minimize this (requiring technical ability):

1. Use QoS and prioritize small packets (< 128 len) as high priority - as most small packets (but not all) are TCP control packets. Alternatively one could expliticly prio SYN, SYN/ACK, ACK, etc. Either way, this will be your biggest win.

2. Turn off TCP timestamps, TCP window scaling, and TCP SACK. While one would think that doing so would diminish the maximum performance of a particular TCP circuit - it's only an issue when a low amount of single circuits are being used in a pure end to end transfer environment. BT is typically not this type of environment, although it looks so on the surface, as the circuits between peers are all of various capabilities and transfer rates. However, the largest reason for turning off these options is that they create additional TCP header overhead - and it is significant within the scope of the header size itself. When dealing with a very chatty and "packety" protocol like BT, one wants to diminish every source of unneeded overhead.

Unfortunately these can't be set on a per-VC basis using setsockopt() calls - one has to use a shotgun approach via /proc/sys/net/ipv4. While changing the settings are easy - you need root to do it.
Nick_13ro
Registered Member
Posts
75
Karma
0

Sun Jun 03, 2007 5:01 am
Ok, so I enable QoS and then what queueing ? Do I need a script too ?
clayne
Registered Member
Posts
16
Karma
0

Sun Jun 03, 2007 9:43 am
Nick_13ro wrote:Ok, so I enable QoS and then what queueing ? Do I need a script too ?


Well just enabling QoS won't do anything. You've got to setup rules to determine which priority levels traffic falls under.

One such rule is what I mentioned, length < 128, highest priority (usually numbered lowest). Web traffic etc following afterwards and then BT typically the lowest priority. This makes it so that BT traffic will be deferred to "normal" traffic. It really depends on the router model you're using, etc. so it's somewhat hard to give anything but generalizations.
Nick_13ro
Registered Member
Posts
75
Karma
0

Sun Jun 03, 2007 10:08 am
Ok, can this be done with the bittorrent client on the router or only if the bittorrent client is behind a router u have to configure with QoS ?


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot]