On Fri, 2005-12-16 at 13:08 +0000, Stroller wrote: > On Dec 15, 2005, at 5:05 pm, Matthias Langer wrote: > > > > Well, i use azureus - and of course i know that upload-speed can be > > limited - which is maybe in fact the best solution to my problem. > > ... for p2p apps - give them > > as much bandwidth they can reasonably get but don't let them slow down > > firefox, ssh etc. Because i want this setup just for my homenetwork, it > > would perfectly suffice if packages get their priorities by examining > > port-numbers. And because i want to at least partially understand what > > i'm doing i would prefer a simple and clean setup. > > I haven't used it yet, but my understanding of traffic-shaping is that > it's exactly what you want. I believe that other quality-of-service > mechanisms may require applications to be QoS aware (setting a QoS bit > in the packet header). > > You're absolutely right in that reducing the bandwidth of the p2p app > isn't the ideal way to achieve what you want - I find latency in > browsing & surfing with BitTorrent consuming only 60% - 70% of my > upload - it doesn't help that other peers are continually making > requests of you. If you lower the bandwidth consumption in Azureous > then you have to remember to up it again when you go to bed - traffic > shaping WILL allow you to permanently maximise your p2p bandwidth, with > the ROUTER reducing it only when your priority services send packets. > > > I know that in > > principle the neccessairy steps to do what i wannt can be found in the > > 'Packet Shaping HOWTO'. .... By the way, > > there are many different packet shedulers in the kernel - and the HOWTO > > only explains the HTP-scheduler. What about the other schedulers - can > > they be usefull for my purposes too - and if yes, how can they be > > configured and used ? > > No idea. I hope you'll give us feedback when you've discovered more.
Ok i found out that in fact the HFSC scheduler should be the one which does exactly what i like because it handles bandwidth and latency seperatley. Here is my current setup, which seems not to be ideal - ssh is still slow when my upload is high: # create the following tree # 1: # 1:1 # 1:10 1:20 1:30 1:40 # where 1:10 is for ssh, 1:20 for svn, 1:30 for surfing and 1:40 for unmatched traffic # creates the root qdisc tc qdisc add dev eth0 root handle 1: hfsc default 40 # node 1:1 tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 441kbit ul rate 441kbit # node 1:10 (ssh) - guaranty 1500b in 20ms with an overarall rate of 88kbit tc class add dev eth0 parent 1:1 classid 1:10 hfsc sc umax 800b dmax 20ms rate 88kbit # node 1:20 (svn) - guaranty 1500b in 30ms with an overall rate of of 147kbit tc class add dev eth0 parent 1:1 classid 1:20 hfsc sc umax 800b dmax 30ms rate 147kbit # node 1:30 (firefox) - garanty 20000b in 100ms with an overall rate of 120kbit tc class add dev eth0 parent 1:1 classid 1:30 hfsc sc umax 20000b dmax 100ms rate 120kbit #node 1:40 (unmatched) tc class add dev eth0 parent 1:1 classid 1:40 hfsc sc rate 96kbit # now that we have our qdiscs we need filters for them # ssh tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:10 # svn tc filter add dev eth0 protocol ip parent 1: prio 2 u32 match ip dport 3690 0xffff flowid 1:20 # firefox tc filter add dev eth0 protocol ip parent 1: prio 3 u32 match ip dport 80 0xffff flowid 1:30 Note that i use the u32 filter (must be enabled in the kernel) and not iptables. By the way, there is a very interesting article about traffic control with qdiscs and different schedulers, in particular HFSC, written by the author of HFSC himself in the german 'Linux Magazin' 02/2005. I'll tell you about further experiences with HFSC - comments and suggestions are welcome. Matthias -- gentoo-user@gentoo.org mailing list
