Date: Fri, 11 Oct 2024 06:55:41 -0600 From: Alan Somers <asomers@freebsd.org> To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: How does the TCP measurement period work? Message-ID: <CAOtMX2jmXNvbEbO%2Bnjec-qGXcuPcrEr4qa-nrhdHjS8%2BrnutJA@mail.gmail.com> In-Reply-To: <7FB6F5E5-C6C0-4C18-B5FD-AEB18F0D5967@lurchi.franken.de> References: <CAOtMX2hKZy9omwHXLpKw42QwpGcUmTwLqSp=OWYYZ8cqOwwQ6w@mail.gmail.com> <7FB6F5E5-C6C0-4C18-B5FD-AEB18F0D5967@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 11, 2024 at 1:05=E2=80=AFAM Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote: > > > On 11. Oct 2024, at 01:07, Alan Somers <asomers@freebsd.org> wrote: > > > > Can somebody please explain to me how the TCP measurement period > > works? When does h_ertt decide to take a new measurement? > > > > Motivation: > > I recently saw a long-distance connection that should've been capable > > of 80+ MBps suddenly drop to < 1 MBps. Subsequent analysis of the > > pcap file showed that while the typical RTT was 16.5 ms, there were a > > few spikes as high as 380ms that coincided with the drop in > > throughput. The surprising part was that even though RTT returned to > > a good value, the throughput stayed low for the entire remaining > > transfer, which lasted 750s. I would've expected throughput to > > recover once RTT did. My theory is that h_ertt never made a new > > measurement. However, I cannot reproduce the problem using dummynet > > on a local VM. With dummynet, as soon as I return the RTT to normal, > > the throughput quickly recovers, as one would expect. > Which TCP stack and which CC module did you use? Which version of FreeBSD= ? I was using the regular freebsd TCP stack with cc_chd. The production system was running FreeBSD 14.1, but my attempts to recreate the situation using dummynet used 15.0-CURRENT.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jmXNvbEbO%2Bnjec-qGXcuPcrEr4qa-nrhdHjS8%2BrnutJA>