lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 4 Sep 2012 09:40:40 -0700 From: Dave Taht <dave.taht@...il.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Nandita Dukkipati <nanditad@...gle.com>, Yuchung Cheng <ycheng@...gle.com>, codel@...ts.bufferbloat.net, Kathleen Nichols <nichols@...lere.com>, netdev <netdev@...r.kernel.org>, Tomas Hruby <thruby@...gle.com> Subject: Re: [RFC v2] fq_codel : interval servo on hosts On Tue, Sep 4, 2012 at 8:34 AM, Eric Dumazet <eric.dumazet@...il.com> wrote: > On Tue, 2012-09-04 at 08:10 -0700, Nandita Dukkipati wrote: >> The idea of using srtt as interval makes sense to me if alongside we >> also hash flows with similar RTTs into same bucket. But with just the >> change in interval, I am not sure how codel is expected to behave. >> >> My understanding is: the interval (usually set to worst case expected >> RTT) is used to measure the standing queue or the "bad" queue. Suppose >> 1ms and 100ms RTT flows get hashed to same bucket, then the interval >> with this patch will flip flop between 1ms and 100ms. How is this >> expected to measure a standing queue? In fact I think the 1ms flow may >> land up measuring the burstiness or the "good" queue created by the >> long RTT flows, and this isn't desirable. Experiments would be good. > > Well, how things settle with a pure codel, mixing flows of very > different RTT then ? Elephants are shot statistically more often than mice. > It seems there is a high resistance on SFQ/fq_codel model because of the > probabilities of flows sharing a bucket. I was going to do this in a separate email, because it is a little off-topic. fq_codel has a standing queue problem, based on the fact that when a queue empties, codel.h resets. This made sense for the single FIFO codel but not multi-queued fq_codel. So after we hit X high rate flows, target can never be achieved, even straining mightily, and we end up with a standing queue again. Easily seen with like 150 bidirectional flows at 10 or 100Mbit. (as queues go, it's still pretty good queue. And: I've fiddled with various means of draining multi-queue behavior thus far, and they ended up unstable/unfair) > So what about removing the stochastic thing and switch to a hash with > collision resolution ? Was considered and discarded in the original SFQ paper as being too computationally intensive (in 1993). Worth revisiting. http://www2.rdrop.com/~paulmck/scalability/paper/sfq.2002.06.04.pdf > > -- Dave Täht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!" -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists