ath5k: Reimplement clock rate to usec conversion

Thanks, Lukas

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

That's strange, those patches can't change anything... They modify a code that cannot be used until patch[5/5] is applied, and even then you probably don't use it, because you didn't say you set the coverage class.

I think there's something wrong with your test methodology, because I don't notice any difference, TCP throughput is always around 3MB/s. However I haven't tried ath5k on both ends yet.

Have you tried setting a fixed rate (via iwconfig, it's not in iw yet)? Or setting a fixed antenna (there's no UI yet, you have to hardcode it, see function ath5k_hw_set_antenna_mode)?

Lukas Turek