Date: Tue, 21 Oct 2014 15:00:36 +1100 From: grenville armitage <garmitage@swin.edu.au> To: freebsd-dtrace@freebsd.org Subject: dtrace tcps_rto bug? Message-ID: <5445DA64.4060506@swin.edu.au>
next in thread | raw e-mail | index | archive | help
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.
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.)
cheers,
gja
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5445DA64.4060506>