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 08:10:36 -0700 From: Nandita Dukkipati <nanditad@...gle.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Yuchung Cheng <ycheng@...gle.com>, codel@...ts.bufferbloat.net, Dave Taht <dave.taht@...il.com>, 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 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. On Sat, Sep 1, 2012 at 5:51 AM, Eric Dumazet <eric.dumazet@...il.com> wrote: > On Fri, 2012-08-31 at 18:37 -0700, Yuchung Cheng wrote: > >> Just curious: tp->srtt is a very rough estimator, e.g., Delayed-ACks >> can easily add 40 - 200ms fuzziness. Will this affect short flows? > > Good point > > Delayed acks shouldnt matter, because they happen when flow had been > idle for a while. > > I guess we should clamp the srtt to the default interval > > if (srtt) > q->cparams.interval = min(tcp_srtt_to_codel(srtt), > q->default_interval); > > > -- 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