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 18:25:18 +0300 From: Jonathan Morton <chromatix99@...il.com> To: Nandita Dukkipati <nanditad@...gle.com> Cc: Eric Dumazet <eric.dumazet@...il.com>, Tomas Hruby <thruby@...gle.com>, netdev <netdev@...r.kernel.org>, "codel@...ts.bufferbloat.net" <codel@...ts.bufferbloat.net> Subject: Re: [Codel] [RFC v2] fq_codel : interval servo on hosts I think that in most cases, a long RTT flow and a short RTT flow on the same interface means that the long RTT flow isn't bottlenecked here, and therefore won't ever build up a significant queue - and that means you would want to track over the shorter interval. Is that a reasonable assumption? The key to knowledge is not to rely on others to teach you it. On 4 Sep 2012, at 18:10, Nandita Dukkipati <nanditad@...gle.com> 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. > > > 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); >> >> >> > _______________________________________________ > Codel mailing list > Codel@...ts.bufferbloat.net > https://lists.bufferbloat.net/listinfo/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