Re: [ath5k-devel] [PATCH 4/5] ath5k: Reimplement clock rate to usec conversion

[海藻敬之 <tkaiso@thinktube.com>]

Thanks, Lukas
> According to my interpretation the calculation should depend 
> on channel width (20MHz in normal mode, 40MHz in turbo mode, same for 802.11g 
> and 802.11a), not on MAC chip clocks. 
thanks, then my guess was irrelevant...
I got some improvement (even not so significant), but I might have
mislead myself at this moment .

let me show my observation during last a few days.

at first
- chip is AR5414
- I pulled down codes via git a week before and your recent patches were
applied.

then what I have observed till now was

1. stable and excellent throughput for 5GHz (with 1hop and also 2hops cases)
16Mbps(1hop) , 8Mbps(2hops)
note: testing with IBSS ad-hoc mode, 1 hop, 2hops , 3 hops..

2. still not good and unstable throughput for 2.4Ghz
thanks to your patch[3/5], [4/5], throughput was improved pretty much
but still staying around 10~15Mbps(1hop), 1Mbps~6Mbps(2hops)

without my experimental patch, 2hops throughput was
worse than the case with that patch.
( 1~2Mbps vs 1~6Mbps --> I can't say this difference is significant ) .
debugfs(rc_stats) shows minstrel reported around 85%~95 success
rate with 48/54Mbps and selected low xmit rate.

(this was the result on limited number of tests. five ~ ten times )

in my these tests, node is sitting pretty close (1m) to each other,
therefore I did not enable RTS/CTS and just counted on physical
carrier sense.

Does it seem that there still exist vulnerable part around carrier
sensing for 2.4GHz.?

anyway,
I would like to get back to this issue, again later

thanks
Taka