[ath5k-devel] Unexpected transmission delay following beacons
-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. Does anyone know why this might occur? Its been suggested by a colleague that it maybe something we've missed in the standard (whereas I was speculating that the tx queues are being stopped/started in the tasklet context and the delay is caused by the vaguaries of tasklet scheduling - I shall check the code to be sure). The configuration consists of an ad hoc link between a single sender and a single receiver using OFDM. The sender saturates the link using iperf and I'm monitoring at a separate station. Most of the time the sender contends after an AIFS[BE] and picks a slot from the expected CW range. There are no re-transmissions so the additional 1ms delay really is quite excessive when we'd expect a average contention window of somewhere around 111 microseconds on average and a maximum of around 187 microseconds. Many thanks Steve -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Wg28ACgkQW7aAm65EWy5aqQCggUkfv4zfFecGAqGNyP/zqJ7Z vHcAoL8yDM5rpJooZGCeGAM+dDHp6/Nv =arU0 -END PGP SIGNATURE- ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Unexpected transmission delay following beacons
Is there stuff in the cabq? Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Unexpected transmission delay following beacons
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
