From owner-cvs-src@FreeBSD.ORG Tue Jul 25 19:38:50 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44D4416A4DE; Tue, 25 Jul 2006 19:38:50 +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 3F76D43D49; Tue, 25 Jul 2006 19:38:49 +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 k6PJcmrf001463; Tue, 25 Jul 2006 15:38:48 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Poul-Henning Kamp" Date: Tue, 25 Jul 2006 15:38:34 -0400 User-Agent: KMail/1.6.2 References: <11633.1153855201@critter.freebsd.dk> In-Reply-To: <11633.1153855201@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607251538.36097.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, David Malone , Sam Leffler Subject: Re: cvs commit: src/sys/net bpf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 19:38:50 -0000 On Tuesday 25 July 2006 03:20 pm, Poul-Henning Kamp wrote: > In message <200607252001.aa18647@salmon.maths.tcd.ie>, David Malone writes: > >> > libpcap does not need to be modified; it works already for > >> > wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO > >> > is a bit of a misnomer; it's not entirely 802.11-specific. > >> > >> Ah, you mean we just exploit DLT_IEEE802_11_RADIO. Hmm... How > >> about processing overhead? Can we synchronize the timestamping > >> with system time? > > > >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). > > You can only do that for a very limited time. To make it work for > more than a fraction of a second you would need to grab the > following data: > > timecounter reading timehands->th_counter->tc_gettimecount() > timecounter width timehands->th_counter->tc_counter_mask > reference count timehands->th_offset_count > reference timestamp timehands->th_offset > scaling factor timehands->th_scale > UTC offset boottimebin > > In total we're talking 4+4+4+12+8+12 bytes = 44 bytes. > > At the expense of a subtraction and an AND, you can save 8 bytes > by storing only the masked counter delta instead of the raw values. > > At the expense of a 96 bit addition, you can add the utc offset > to the boottimebin, and save another 12 bytes. > > That would bring it down to 4+12+8 = 24 bytes. I hit send button before I read this. :-) Yes, that's exactly what I meant. BTW, what's your opinion on extending timecounter API to be able to register/deregister trivial timecounter? Jung-uk Kim