On Thu, Nov 30, 2017 at 10:55 AM, Eric Dumazet <eric.duma...@gmail.com>
wrote:

> On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote:
> > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet <eric.duma...@gmail.com
> > > wrote:
> > > I agree that TCP itself should generate ACK smarter, on receivers
> > > that
> > > are lacking GRO. (TCP sends at most one ACK per GRO packets, that
> > > is
> > > why we did not feel an urgent need for better ACK generation)
> > >
> > > It is actually difficult task, because it might need an additional
> > > timer, and we were reluctant adding extra complexity for that.
> >
> > How about just using the existing delayed ACK timer, and just making
> > the delayed ACK logic a bit smarter? We could try using the existing
> > logic and timers, but using something adaptive instead of the magic
> > "2" MSS received to force an ACK.
>
> Keep in mind some distros have HZ=250 or even HZ=100
>
> So even a 'one jiffie' timer could add 10ms delay.
>

Right, good point. I forgot about those cases. :-)

neal
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to