Date: Thu, 7 Jun 2018 20:07:08 -0700 From: Matthew Macy <mat.macy@gmail.com> To: hiren panchasara <hiren@strugglingcoder.info> Cc: Randall Stewart <rrs@netflix.com>, Randall Ray Stewart <rrs@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334804 - in head/sys: kern modules/tcp modules/tcp/rack netinet netinet/tcp_stacks sys Message-ID: <CAPrugNo4bHERR-Cs5o4io5-Lnw0tz6ZN=oe3H2BSH1LgdZBubg@mail.gmail.com> In-Reply-To: <20180608015740.GD62424@strugglingcoder.info> References: <201806071818.w57IIENp080093@repo.freebsd.org> <20180607220121.GC62424@strugglingcoder.info> <40CCC8B4-5667-4D4B-A4B4-7AD5779FE011@netflix.com> <20180608015740.GD62424@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Okay. I believe there might be situations where we may want to still > keep the 'default' stack alive. I know Windows doesn't yet use RACK when > rtt is lesser than 10ms (or something like that), as an example. > Is there any reason RACK wouldn't work for tracking 10us RTTs? If we know we know the peer doesn't do delack or have enough data in flight and the other stack doesn't have broken LRO, could we just use this in lieu of high resolution timestamps? -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPrugNo4bHERR-Cs5o4io5-Lnw0tz6ZN=oe3H2BSH1LgdZBubg>