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. 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.
