Re: proposal: rename DLT_PRISM_HEADER

[Solomon Peachy <solomon () linux-wlan com>]

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                        solomon () linux-wlan com
AbsoluteValue Systems                 http://www.linux-wlan.com
715-D North Drive                     +1 (321) 259-0737  (office)
Melbourne, FL 32934                   +1 (321) 259-0286  (fax)

Attachment: _bin
Description: