From: Pedro Estrela (pedro.estrela_at_inesc.pt)
Date: 2001-12-18 21:30:19 UTC
I've studyed the 802.11 MAC overhead, and the major bandwith killer is the
"level 1" preamble that precedes the mac header and all the rest.
This preamble, in normal 802.11, equals to 24 bytes. that would be fine (for
example, 802.11 data packets MAC header equals 34 bytes, and ethernet 14) if
it it wouldn't be for auto-fallback to lower rates when the distance
increases.
this way, the 24 bytes for each packet really equals 264 bytes in 11Mbit/s
terms, wich is something completly different;
and beacuse the standard defines that all packets are acked, for each one IP
packet there are 2 of these long PHY preambles... (there are other sources
os overhead, but this one is the major).
back to your ideia,
i'll would be great; i've seen other systems (non-standard) derived from
802.11 that delays ACKS, and gives much greater bandwith.
But normal 802.11 works this way, and the acks MUST be sent in a very timely
manner. That way, they are very deep within the firmware... and it's not
possible to disable it.
Pedro
> Has anyone investigated the possibility or desireability of modifying this
> driver such that essentially 802.11b ACK frames are removed, e.g. the
> (data) recipient doesn't send one, and the would-be receiver doesn't
> expect one?
>
> The goal of course is to reduce protocol overhead in dedicated-purpose
> wireless links, and perhaps the low levels exposed by the PrismII MAC is
> the only way to accomplish this with standard hardware and no access to
> firmware.
>
> This of course would only be compatible with similarily modified systems.
>
> Re-sends would be handled by higher level protocols that need them, I
> believe somewhat transparenlty. The usage scenario again would be on more
> sure, stationary links where receivability is somwhat assured.
>
> Jerritt
>