* [LARTC] SFQ clarification
2001-02-10 1:38 [LARTC] SFQ clarification Don
@ 2001-02-10 4:04 ` Gregory
2001-02-10 5:14 ` Don
1 sibling, 0 replies; 3+ messages in thread
From: Gregory @ 2001-02-10 4:04 UTC (permalink / raw)
To: lartc
<PRE>On Fri, Feb 09, 2001 at 05:38:18PM -0800, Don Cohen wrote:
><i> <A HREF="http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html">http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html</A>
</I>><i> 9.2 Stochastic Fairness Queueing
</I>><i> says:
</I>><i> SFQ however cannot determine interactive flows from bulk ones -- one
</I>><i> usually needs to do the selection with CBQ before, and then direct the
</I>><i> bulk traffic into SFQ.
</I>><i>
</I>><i> I don't understand this. You want to give preference to the non-bulk
</I>><i> traffic, right? And this is what you get if you just put it all into
</I>><i> the same SFQ, right? All the small flows get fast service and the
</I>><i> large flows fairly share what's left. That seems like what you want.
</I>><i> So it's true that SFQ does not distinguish bulk from interactive flows
</I>><i> but there's no need to.
</I>
No, in the context of network queue management bulk means non-interactive,
batch might be a better word.
SFQ classfies packets by computing hash(shost,dhost,sport,dport,proto,seed)
where hash produces an output of 0-1023. The system then creates 1024 queues
(virtually) and pulls a single packet from each one in a round-robin fashion.
(roughly)
Thus each of these 1024 buckets gets an equal chance at bandwidth. As the
number of flows approaches 1024 the probability of two flows ending up in
the same bucket approaches 100%. Two flows in the same bucket fight over
bandwidth as do flows in a classic tail-drop router. At a regular interval
the 'seed' is changed to cause differnt flows to be batched togeather.
Notice above I said, 'equal chance' at bandwith. That doesn't mean equal
bandwidth. Consider 3 active buckets, one with your slogin text, two with
outbound file transfers. It will transmit one character (perhaps, depends on
nagle) of your slogin, then two ~1500byte file transfer packets, then
another few bytes of telnet, then it has to wait for another two 1500byte
file transfer packets. Not exactly fair..
So SFQ is only fair when all the needs are simmlar..
So, the preferable queue arrangement could be something like something like:
1[TBF]-[TOS: Minimize delay]
[eth]-[PRIO]/2[SFQ]-[EVERYTHING ELSE]
\3[SFQ]-[TOS: Lowest cost]
The TBF on the minimize delay is just prudence to prevent 'wow, if I check
minimize delay I can transfer big files FAST'
Unfortunatly, Linux currently doesn't have any SF red queues (or SFB) which
would have improved performance over SFtail-drop (which is what SFQ is).
Additionally, Linux doesn't allow you do specify the hash size for your SFQ,
which could make it less useful in some situations.
</PRE>
^ permalink raw reply [flat|nested] 3+ messages in thread* [LARTC] SFQ clarification
2001-02-10 1:38 [LARTC] SFQ clarification Don
2001-02-10 4:04 ` Gregory
@ 2001-02-10 5:14 ` Don
1 sibling, 0 replies; 3+ messages in thread
From: Don @ 2001-02-10 5:14 UTC (permalink / raw)
To: lartc
<PRE>Gregory Maxwell writes:
> On Fri, Feb 09, 2001 at 05:38:18PM -0800, Don Cohen wrote:
> > <A HREF="http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html">http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html</A>
> > 9.2 Stochastic Fairness Queueing
> > says:
> > SFQ however cannot determine interactive flows from bulk ones -- one
> > usually needs to do the selection with CBQ before, and then direct the
> > bulk traffic into SFQ.
> >
> > I don't understand this. You want to give preference to the non-bulk
> > traffic, right? And this is what you get if you just put it all into
> > the same SFQ, right? All the small flows get fast service and the
> > large flows fairly share what's left. That seems like what you want.
> > So it's true that SFQ does not distinguish bulk from interactive flows
> > but there's no need to.
>
> No, in the context of network queue management bulk means non-interactive,
> batch might be a better word.
>
> SFQ classfies packets by computing hash(shost,dhost,sport,dport,proto,seed)
> where hash produces an output of 0-1023. The system then creates 1024 queues
> (virtually) and pulls a single packet from each one in a round-robin fashion.
> (roughly)
>
> Thus each of these 1024 buckets gets an equal chance at bandwidth. As the
> number of flows approaches 1024 the probability of two flows ending up in
> the same bucket approaches 100%. Two flows in the same bucket fight over
> bandwidth as do flows in a classic tail-drop router. At a regular interval
> the 'seed' is changed to cause differnt flows to be batched togeather.
I see, you're worried about the case where there are lots of flows
(compared to 1024). I had assumed that the object was to pick a
number of buckets that made it unlikely for two flows to share a
bucket. You agree with me in the case where each flow has its own
bucket, right?
> So SFQ is only fair when all the needs are simmlar..
I think it's fair when each flow has its own bucket.
> Unfortunatly, Linux currently doesn't have any SF red queues (or SFB) which
> would have improved performance over SFtail-drop (which is what SFQ is).
> Additionally, Linux doesn't allow you do specify the hash size for your SFQ,
> which could make it less useful in some situations.
It's not linux but this particular SFQ module (which seems pretty easy
to change) that doesn't let you specify the number of buckets at run
time.
</PRE>
^ permalink raw reply [flat|nested] 3+ messages in thread