On Thu, Jun 28, 2012 at 11:12 AM, Eric Dumazet <[email protected]> wrote: > On Thu, 2012-06-28 at 10:51 -0700, Dave Taht wrote: > >> clever idea. A problem is there are other forms of network traffic on >> a link, and this is punishing a single tcp Dave: it won't just punish a single TCP, all protocols that react to XMIT_CN will share similar fate.
>> stream that may not be the source of the problem in the first place, >> and basically putting it into double jeopardy. >> > > Why ? In fact this patch helps the tcp session being signaled (as it > will be anyway) at enqueue time, instead of having to react to packet > losses indications given (after RTT) by receiver. > > Avoiding losses help receiver to consume data without having to buffer > it into Out Of Order queue. > > So its not jeopardy, but early congestion notification without RTT > delay. > > NET_XMIT_CN is a soft signal, far more disruptive than a DROP. I don't read here: you mean far "less" disruptive in terms of performance? > >> I am curious as to how often an enqueue is actually dropping in the >> codel/fq_codel case, the hope was that there would be plenty of >> headroom under far more circumstances on this qdisc. >> > > "tc -s qdisc show dev eth0" can show you all the counts. > > We never drop a packet at enqueue time, unless you hit the emergency > limit (10240 packets for fq_codel). When you reach this limit, you are > under trouble. Another nice feature is to resume TCP xmit operation at when the skb hits the wire. My hutch is that Eric is working on this too. > > > _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
