On Sunday 04 December 2005 19:17, Brian J. Murrell wrote: > > There is no fair treatment in PRIO. > > No, it's priority based. Got that. Exactly what I am looking for in > fact. Sorry, seems that I misunderstood you in your message in the point that you meant SFQ and not PRIO when you were talking about fair treatment. > 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 Without additional filter rules, it should be 'default 1', and not 10. Otherwise HTB will try to put the classes in 1:10, which does not exist, and instead send them out directly without any shaping at all. > 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? Hmmm. Well, I was just guessing, because I had this 'stuck' problem with TBF before. As I said, I never really solved that problem, so I can't say much about cause and such. The way I understand it, the root qdisc will get the request to dequeue a packet, and it will forward this request to the underlying qdiscs. So when TBF is asked for a packet, it will decide wether to send one or not (depending on wether there is any bandwidth left). If it wants to dequeue one, it will forward this request to the underlying queue(s), PRIO in your case. PRIO will look at it's bands and dequeue a packet from the first band that has packets queued; in your case, it will have to ask the underlying SFQ queue to select a packet. SFQ will look at the packets it has queued and select one based on it's "stochastical fairness" algorithm. SFQ then returns this packet to PRIO which in turn will return this packet to TBF which in turn will send this packet on it's way. Please note that this is all guesswork. I haven't actually looked at the kernel code for all of that. :-) It might actually work in a totally different way. Anyway, if my understanding model is correct, and some packets in your prio bands get sent and others don't, it should be the fault of SFQ, and not PRIO, for selecting the wrong packets. My guess before was that TBF was at fault, allowing too little bandwidth, which would lead to a general stalling, which would be most noticeable on connections that are bandwidth intensive. A completely different reason may be that you've got a bad mixing of flows; for example, "important" traffic like web browsing etc., and P2P don't go well together in the same queue. This is simply because P2P has the habit of opening hundreds of connection, whereas WWW is just one or at least very few connections. So if you've got maybe 5 WWW connections and 200 P2P connections flowing through the same SFQ queue, every connection will be able to send about the same number of packets, resulting in a lot of P2P packets and very few WWW packets, just because there are so many more P2P connections there. For that very reason, in my P2P setups I'm actually using 4 prio bands, putting P2P alone into the 4th band, so that it may starve when there is any traffic other than P2P. > I think I am doing that. I thought that is what: > > 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 I apologize; I'm guilty of not reading your messages carefully enough. Regards, Andreas Klauer _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
