On Sun, 2005-12-04 at 17:54 +0100, Andreas Klauer wrote: > On Sunday 04 December 2005 17:36, Brian J. Murrell wrote: > > Even if they end up in 2:3, they should at least be treated fairly. > > 2:3 will not be treated at all as long as 2:1 and 2:2 (which have higher > priority) are occupied. Right. I think I said in my last message that both 2:1 and 2:2 were very quiet (which is what I would expect) and that there was a lot of traffic going through 2:3. My point there was that even if 2:3 was processing a lot of packets, since it is an SFQ, everybody should eventually get use of it. > If the queues in 2:1 and 2:2 resp. never empty, > the packets in 2:3 will never be sent. Understood. But they were empty and lots of packets from 2:3 were being sent. > There is no fair treatment in PRIO. No, it's priority based. Got that. Exactly what I am looking for in fact. > That's the whole purpose of this scheduler, to give one band of packets > absolute priority over the other. Yup. My "interactive"/latency sensitive traffic should always get best service. > This is just out of personal interest, but could you try using instead of > your TBF qdisc, a very simple HTB Qdisc / class with the same bandwidth > limitation? Hrm. OK. But I'm not sure how I would use HTB to replace a classless TBF though. for TBF I use: tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit burst 1200 limit 1 So to replace that with HTB I tried: tc qdisc add dev ppp0 root handle 1: htb default 10 tc class add dev ppp0 parent 1 classid 1:1 htb rate 120kbit But nothing seems to be getting put into any of the child classes which are configured as: tc qdisc add dev ppp0 parent 1:1 handle 2: prio bands 3 tc qdisc add dev ppp0 parent 2:1 handle 10: sfq perturb 20 tc qdisc add dev ppp0 parent 2:2 handle 20: sfq perturb 20 tc qdisc add dev ppp0 parent 2:3 handle 30: sfq perturb 20 I'm probably misunderstanding all of the class naming and handles and such. > If that solves the problem, then you're suffering from a > problem that I failed to solve when I last tried to use TBF; for some > reason it got stuck on me too. Well, TBF does not seem to be getting stuck. There is still lots of traffic moving when these other flows seem to just stop, so TBF can't be the problem can it? It has to be PRIO, not dequeuing anything for these particular stalled flows to TBF right? > I don't understand what you mean by fair treatment, but do try putting all > ACKs into high priority band, then it will have to be dequeued. I think I am doing that. I thought that is what: 859K 42M CLASSIFY tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x10 length 0:128 CLASSIFY set 2:1 in the POSTROUTING chain should be doing. It's the result of the iptables rule: iptables -t mangle -I POSTROUTING -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST,ACK ACK -m length --length :128 -j CLASSIFY --set-class 2:1 b. -- My other computer is your Microsoft Windows server. Brian J. Murrell
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
