On Thursday 10 June 2004 16:07, Greg Stark wrote: <snip> > I'm using sfq as well. But I'm wondering if I wouldn't be better off with > pfifo with a short queue. One of the entries in the HTB faq suggests using > sfq can make it hard to limit bandwidth precisely because it requires > enough memory that tcp_wmem kicks in. Or is that only for locally generated > traffic? I tried sticking a limit 10 pfifo on my PRIO n:1 to no avail. ICMP which I add to that class wasn't any better off. The only sure thing I found was to continually reduce my rate. I find for best performance I'm stuck with 62.5% of my 256Kbps upstream. (We really need some kind of realtime PPPoATM scheduler.) I can run at 75%, but the lag is noticeable when browsing the Web, for example. As for SFQ, you can use ESFQ which lets you specify the actual queue limit I believe, or you can recompile SFQ and redefine[1] the queue length in the source code. [1] http://www.docum.org/stef.coene/qos/faq/cache/21.html <snip> > I'm still unsure whether I want to be using iptables to mark packets or > stick with the tc filters I inherited from wshaper. I'd suggest going with IPTables/Netfilter. You can't really go wrong. If you're running a firewall with IPTables already, then you're good to go. Plus, you cannot deal with most p2p traffic using straight `tc` filters. As always, I suggest IPP2P and L7-Filter for 2.4 and 2.6 respectively. L7 seems to catch 99 - 100% of my 'edonkey' traffic. > Marking packets in iptables has the advantage that it knows which packets > were natted and what the host on the far side of the NAT is. It also has > some more flexible methods for matching. > > One thing I'm wondering, is it possible in iptables to mark all packets > after some amount of traffic? Like, for example I want port 80 traffic to > be higher priority than ftp-data and bittorrent, but only for regular > browsing. If I download something over, say, 200k I want to to get > downgraded to the same group as ftp-data and bittorrent. Also, bittorrent > has a habit of occasionally using random ports and doesn't set TOS. So if > iptables knew that that flow had already transfered more than some > threshold of data it could downgrade it. Yes, you can do that. I have been meaning to do it for my HTTP traffic but I keep forgetting. You might try something like this[2]. Or maybe this[3]. [2] http://www.docum.org/stef.coene/qos/faq/cache/49.html [3] http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-connbytes > Actually another possibility is any flow open for more than, say, 30s could > be downgraded. I just read a paper somewhere that mentioned research into that approach. Wish I could remember where I found it now. It was suggested that giving short flows a higher priority over longer lived flows would result in better performance for both. > I don't think the qdiscs handle things at this granularity, but iptables > sure does. I don't recall seeing any of these features but it doesn't seem > like it would be much of a stretch for it. You might check out some of the other patch-o-matic extensions at the above URL. _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
