Re: [LARTC] SFQ buckets/extensions

[don-lartc@isis.cs3-inc.com (Don Cohen)]

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/