Re: [LARTC] SFQ clarification

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gregory Maxwell writes:
 > On Fri, Feb 09, 2001 at 05:38:18PM -0800, Don Cohen wrote:
 > > http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html
 > > 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.



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux