-----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
