Hello again Martin, More comments below: > : So the priorities are useless in real world with pfifo_fast, is > : that it? This is bit surprising, IIUC. This is why I asked. > > Priorities are useless in the real world on a link that we expect to > be congested (e.g. an ADSL link). If the link is not congested, > there's no problem with using priorities. The question is not > whether priorities are useless, but rather, how often do you expect > your link to be congested? Good point... and the answer is: allways. With the low DSL uploads available a single connection will saturate it - we currently have 20Mbs/400kbps (!) services, for example. > > : What I was initially looking for was just TOS marking + plus > : simple interface throtlling, i.e, the simplest form of shapping. > : If it can't be done with pfifo_fast, my next idea was something > : like: > : > : tc qdisc add dev eth0 root handle 1: htb default 10 > : tc class add dev eth0 parent 1: classid 1:1 htb rate 7000kbps ceil 7000kbps > : tc class add dev eth0 parent 1:1 classid 1:10 prio > : > : + > : > : iptables rules for setting TOS values > : > : Is this right? This seems to be similar to what you proposed > : here: > : > : http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html > > Well, indeed, I did post that! While that may solve the problem of > the bottleneck, I have to confess, it's not a very good solution > either! I'll post a follow-up to that thread shortly. > Great. Meanwhile, I just finished my first trial on this approach. The result is here: http://downloads.angulosolido.pt/QoS/PRIO_shaper.sh For SSH interactive traffic and Web Browsing while uploading and downloading, seems to work as well as HTB_shaper, it tested on a single machine. Of course there is no fairness on each prio band, so tests with multiple workstations should reveal the advantadges of HTB_shaper. > : For a not so simple approach but which seems to be working well, > : I have an adaption of Dan Singletary's script here: > : > : http://downloads.angulosolido.pt/QoS/ > : > : It uses directly HTB on both directions, for a setup with only 2 > : network interfaces which is very common (no kernel patching is > : needed). > > HTB in both directions is probably the best way to go (shaping > upload and shaping download). I haven't examined the HTB_shaper.sh > assiduously, but from a quick review, it seems quite reasonable > (and better than my off the cuff remark in the earlier thread). > > I'm not crazy about the dropping of the MTU, but otherwise, I found that it was causing problems, so that part is gone. > the > script seems to make sense. Basically divide up link capacity into > components and limit the total transmission rate to the link > capacity (so we are the bottleneck). > > Then, put some packets in each class. It's so far the best (and > most general) solution in this thread. > > : Still, I want to test the simplest possible solution and see how > : far one can go with only a few lines of bash, for both practical > : and pedagogical purposes. I think it's important to have a simple > : solution that works for typical scenarios (2 interfaces, linux > : router with NAT) on stock kernels. ** > : > : ** nothing wrong about patching and compiling kernels, but it > : brings maintenance overhead everytime there is system upgrade > : for whatever reason > > Understood on the kernel patching/compiling business. That's not > usually something you want to throw at beginners. > And I also don't like to throw it at myself, if it's not really necessary. (OT: I wonder, if the kernel team doesn't want to include IMQ, what's their recommended solution for this problem, on a router with more than 2 interfaces) > Well, if the goal is practical administration and pedagogy, I'd > suggest tcng [0], since the "beauty" of tc is hidden from the user. > The language of tcng feels more like a programming language than the > arcana of tc. > Thank you for the link. I wasn't aware of this project. Best regards Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt > Good luck, > > - -Martin > > [0] http://tcng.sourceforge.net/ > > - -- > Martin A. Brown > http://linux-ip.net/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) > > iD8DBQFEswsEHEoZD1iZ+YcRAhwGAJkBlygjpO6dfT9s+1/yHq91pSAJCQCg8E2a > LRjKTkGjSvQHTLaFReomSlk= > =ikoL > -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
