On Thu, Oct 13, 2011 at 2:21 AM, Steve Glass <stevie.gl...@gmail.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> I'm verifying a model of the 802.11 channel contention behaviours
> experimentally and have discovered something odd i in ath5k which I
> don't understand. It appears that both before and after sending a
> beacon a station incurs an unexplained delay which adds between 1 and
> 1.5ms of lost time.
One interesting data point would be the time at which the beacon was
queued vs when it went over the air. Besides sprinkling printks, one
way you can get that is to use the ath5k tracepoints to collect the
packets on the sender (at queue time) and compare it to the packets
received by your monitor. That should at least answer your question
as to whether it is caused by scheduling on the host.
You can do this via something like:
# trace-cmd record -p function \
-l ieee\* -e ath5k\* -e mac80211\* sleep 300
That grabs any functions called ieee_*, as well as events in ath5k and
mac80211 for five minutes. Then you can grab
http://bobcopeland.com/srcs/ath5k_trace.py and put it in your
~/.trace-cmd/plugins directory, and do:
$ trace-cmd report > trace.out
That will create a text listing of the tracepoints in trace.out, as
well as a pcap file with the packet info in /tmp/pcap.out.
--
Bob Copeland %% www.bobcopeland.com
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
