Date: Mon, 20 Oct 2014 22:23:56 -0700 From: Mark Johnston <markj@FreeBSD.org> To: grenville armitage <garmitage@swin.edu.au> Cc: freebsd-dtrace@freebsd.org Subject: Re: dtrace tcps_rto bug? Message-ID: <20141021052356.GA38615@charmander.picturesperfect.net> In-Reply-To: <5445DA64.4060506@swin.edu.au> References: <5445DA64.4060506@swin.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 21, 2014 at 03:00:36PM +1100, grenville armitage wrote:
>
> I'm curious about dtrace's args[3]->tcps_rto calculation.
>
> Right now /usr/src/cddl/lib/libdtrace/tcp.d defines tcps_rto as:
>
> typedef struct tcpsinfo {
> [..]
> uint32_t tcps_rto; /* round-trip timeout, msec */
> [..]
> } tcpsinfo_t;
>
> And then later derives tcps_rto from p->t_rxtcur like so:
>
> tcps_rto = p == NULL ? -1 : p->t_rxtcur / 1000; /* XXX */
>
> I doubt this is right.
>
> t_rxtcur is the kernel's notion of RTO in ticks (as per netinet/tcp_var.h), so for a kernel where HZ=1000 the preceding calculation would result tcps_rto being the RTO in seconds (not milliseconds, as stated in the struct tcpsinfo definition). And for kernels where HZ != 1000, all bets are off.
Right. I'm not sure what I was thinking when I wrote that line. :(
>
> Inside a dtrace .d file we can use "`hz" to represent the running kernel's current tick rate (kern.hz), so I believe the correct expression for tcps_rto would be:
>
> tcps_rto = p == NULL ? -1 : (p->t_rxtcur * 1000) / `hz;
>
> (I've run a few simple tests, and this change seems to produce plausible RTO values in milliseconds when args[3]->tcps_rto is read from inside a tcp:::send probe.)
I've committed the change as r273370. Thanks!
-Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141021052356.GA38615>