From owner-cvs-all@FreeBSD.ORG Tue Jul 25 19:39:26 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B084616A4DD; Tue, 25 Jul 2006 19:39:26 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 0274543D70; Tue, 25 Jul 2006 19:39:21 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 25 Jul 2006 20:39:21 +0100 (BST) To: Jung-uk Kim In-reply-to: Your message of "Tue, 25 Jul 2006 15:25:10 EDT." <200607251525.11623.jkim@FreeBSD.org> Date: Tue, 25 Jul 2006 20:39:16 +0100 From: David Malone Message-ID: <200607252039.aa40648@salmon.maths.tcd.ie> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, "Christian S.J. Peron" , cvs-all@FreeBSD.org, phk@FreeBSD.org, Sam Leffler Subject: Re: cvs commit: src/sys/net bpf.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 19:39:26 -0000 > > It sounds to me like a reasonable thing to do would be to pass up > > a raw version of the timestamp (as returned by the hardware). We'd > > also pass up the regular microtime() timestamp. You can then do any > > postprocessing to syncronise timestamps later in userland? > Nope. In that case, you actually need to export few more things, > i.e., current hardware timecounter value, clock frequency, size of > the timecounter, etc. Even then, it's going to be hard to get > correct timeval without exposing few kernel internals. I guess it depends a bit on your requirements. If you have a sequence of packets and are interested in getting accurate inter-arrival times, then (providing that the counter doesn't wrap too often and the frequency is relatively constant) the hardware counter values and system timestamps of the first and last packets should be enough to get quite close to what you want. (This might even produce better estimates of inter-rival times than also using the intermediate timestamps, as NTP slewing the clock can make it hard to get consistent readings. Hence people doing stuff like this http://www.imconf.net/imc-2004/papers/p219-veitch.pdf) You're right though - that's not sufficient for everyone. David.