On Wed, Dec 18, 2002 at 04:52:11PM -0600, David Young wrote: > What can we afford in terms of header length and CPU cycles spent parsing? > I don't know what the outer acceptable figures are. How do you think > those considerations weigh against the conveniences of LTVs I mention?
A lot of this work is done inside hard interrupt context on very underpowered embedded systems. I don't have any numbers to give you, unfortunately. Because if fields are tagged and "optional" what will happen is that drivers will just add all fields. That's what happened with the old DLT_PRISM header; technically all fields were tagged and optional, but nobody (not even us *sheepish grin*) bothered to use the header properly, instead using a full 144 bytes for a header that only contained maybe 30 bytes of "useful" data. Hell, amny of 'em didn't even populate the id/length properly at the beginning of the header. :) > In any case, I will reluctantly adopt the present format with unspecified > mactime units. I will *gladly* adopt the format if the units for mactime > are fixed at nanosecond resolution or higher, or given by a new header > field. It is counter to the purpose of a unified radio header format to > let the units change from one adapter to another. So, there are two alternatives: 1) Fix the mactime to be in, say, nanoseconds as you suggested. 2) Add another field that describes the mactime. The Intersil prism2 series provides microsecond accuracy; I can't speak for any of its variants/derivatives (eg orinoco and cisco). I'm inclined to go for (1), as if the hardware proveides a timestamp, the units will be known. Sound good? - Pizza -- Solomon Peachy [EMAIL PROTECTED] AbsoluteValue Systems http://www.linux-wlan.com 715-D North Drive +1 (321) 259-0737 (office) Melbourne, FL 32934 +1 (321) 259-0286 (fax)
msg02114/pgp00000.pgp
Description: PGP signature
