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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace
To unsubscribe, send any mail to "[email protected]"
