cvs commit: src/sys/net bpf.c

[Jung-uk Kim]

On Tuesday 25 July 2006 03:20 pm, Poul-Henning Kamp wrote:
> In message <200607252001.aa18647 at 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