From owner-freebsd-dtrace@FreeBSD.ORG  Tue Oct 21 04:00:41 2014
Return-Path: <owner-freebsd-dtrace@FreeBSD.ORG>
Delivered-To: freebsd-dtrace@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 2658D612
 for <freebsd-dtrace@freebsd.org>; Tue, 21 Oct 2014 04:00:41 +0000 (UTC)
Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 9EBC3915
 for <freebsd-dtrace@freebsd.org>; Tue, 21 Oct 2014 04:00:40 +0000 (UTC)
Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37])
 by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id s9L40aZK023023
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); 
 Tue, 21 Oct 2014 15:00:37 +1100
Message-ID: <5445DA64.4060506@swin.edu.au>
Date: Tue, 21 Oct 2014 15:00:36 +1100
From: grenville armitage <garmitage@swin.edu.au>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:16.0) Gecko/20121107 Thunderbird/16.0.2
MIME-Version: 1.0
To: freebsd-dtrace@freebsd.org
Subject: dtrace tcps_rto bug?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-dtrace@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "A discussion list for developers working on DTrace in FreeBSD."
 <freebsd-dtrace.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-dtrace>, 
 <mailto:freebsd-dtrace-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-dtrace/>
List-Post: <mailto:freebsd-dtrace@freebsd.org>
List-Help: <mailto:freebsd-dtrace-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace>,
 <mailto:freebsd-dtrace-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Oct 2014 04:00:41 -0000


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