Alexander Atanasov writes: > > Again, no. It's perfectly possible for one queue to always have > > length in range 99-101 and another to always have length 9-11 and > > still be serving them both at the same rate. Just imagine that one > > client sends 100 packets at once and the other sends 10 at once and > > then they each send one per second and we forward one per second. > > Same rate (suppose all packets are same length), different queue > > lengths. In fact SFQ serves them at the same rate no matter how long > > they are. Note - serving in this case means sending, not receiving. > > Okay, we said that sfq dropes from the longest subqueue. > We start with: > q1 - 100 > q2 - 10 > > we enqueue(recive) 2 packets/sec I meant one from each source > and dequeue(send) 1 packet/sec. ( rr from q1 and q2 ). I meant one from each subqueue So we're in steady state. After one second we have sent one from each subqueue and it has been replenished. > q1 will grow to the limit first so sfq will start to drop there, The total queue size is not growing so nothing is being dropped. Maybe you think it's just incredibly lucky that these sources are both sending at just the same rate that they're being served, but that's what tcp is supposed to do. > Measurement in bytes can make this more incorrect since you have enqueued > packets with different lenghts which you can not split a part and dequeue > in bytes (sigh wouldn't it be nice? ), counting queues in packets (exactly > what they have) is better. May be doing it like the cbq with average > packet size can gave us better results. No, the errors are accumulated. It's always within one packet of the ideal in terms of what's sent. The advantage of measuring queue length in bytes would be more fairness in dropping, i.e., you should drop from a queue with 10 packets each of length 1000 bytes instead of a queue with 20 packets each of length 100 bytes. > People wanted options to tune hashsize/limits/depths and > the most wanted (needed) was the option to select hash type. > SRC/DST Port hash is in TODO now. > Searching gives answers like "Patch SFQ", but that just doesn't > worked for me.i need to have different sfqs on different > classes/interfaces. So that's why there is an esfq. And i hope it really > helps. I think the version I sent does give control over queue size and number of buckets. It also gives you something called expire, which I think might do the same sort of thing that you wanted from your limits. We've discussed it on this list before so I won't go into it again. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
