On Tuesday 25 July 2006 03:20 pm, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
