From owner-cvs-all@FreeBSD.ORG Tue Jul 25 20:12:01 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 8D79616A644; Tue, 25 Jul 2006 20:12:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id F007D43D45; Tue, 25 Jul 2006 20:12:00 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k6PKBdE3002825; Tue, 25 Jul 2006 16:11:41 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: David Malone Date: Tue, 25 Jul 2006 16:11:25 -0400 User-Agent: KMail/1.6.2 References: <200607252039.aa40648@salmon.maths.tcd.ie> In-Reply-To: <200607252039.aa40648@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607251611.27316.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1618/Mon Jul 24 21:12:40 2006 on anuket.mj.niksun.com X-Virus-Status: Clean 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 20:12:01 -0000 On Tuesday 25 July 2006 03:39 pm, David Malone wrote: > > > 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. Well, it may not be close enough because between actual packet arrival time and calling microtime() is not always constant. Actually, it's not even close from my experience, not to mention device polling and interrupt moderation issues. :-( Of course, it all depends on device driver and network controller design, though. > (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) It is not too easy as I said. BTW, for designing and implementing wonderful API for FreeBSD, we should be thankful for having phk in the team. > You're right though - that's not sufficient for everyone. I really like to have both generic and flexible API. :-) Jung-uk Kim