From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EncTf-0001W3-ED for garchives@archives.gentoo.org; Sat, 17 Dec 2005 13:51:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBHDnSqT030275; Sat, 17 Dec 2005 13:49:28 GMT Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBHDlWmQ008308 for ; Sat, 17 Dec 2005 13:47:33 GMT Received: (qmail invoked by alias); 17 Dec 2005 13:47:30 -0000 Received: from chello080108115144.1.11.univie.teleweb.at (EHLO sputnik886) [80.108.115.144] by mail.gmx.net (mp029) with SMTP; 17 Dec 2005 14:47:30 +0100 X-Authenticated: #28563408 Subject: Re: [gentoo-user] traffic shaping and p2p From: Matthias Langer To: gentoo-user@lists.gentoo.org In-Reply-To: References: <1134586948.9339.22.camel@sputnik886.ruz-net> <43A120E5.1070603@gmail.com> <1134666315.9856.23.camel@sputnik886.ruz-net> Content-Type: text/plain Date: Sat, 17 Dec 2005 14:47:13 +0100 Message-Id: <1134827233.12384.24.camel@sputnik886.ruz-net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Archives-Salt: 2b2e1382-7632-473f-9b1e-71948b57e8c2 X-Archives-Hash: d79da0fef4115491215fed715647a92f 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