( sorry again for my last post which was corrupted. I do not why... some coding issue.. please be patient. )
Lukas thanks. >> 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) >> > 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. > My work did not include "coverage class". I just applied [3/5], [4/5]. Before applying [4/5], ath5k_hw_clocktoh() takes care of 11a but 11g/b, and your new ath5k_he_get_clockrate() handles both 11a and 11b/g, correct ? Therefore, I thought this can make difference in throughput. am I wrong on this point ? > 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. > Ok, I should check my tests and will do it again carefully. In my cases, I am always playing with IBSS ad-hoc mode on all nodes and noticed that the throughput got so bad for 2 hops forwarding( A->B->C ) scenario. 3Mbps/TCP is so low, isn't it ? how long is it between the two nodes ? > Have you tried setting a fixed rate (via iwconfig, it's not in iw yet)? > currently, no > Or setting a fixed antenna (there's no UI yet, you have to hardcode it, see > function ath5k_hw_set_antenna_mode)? > > currently no. let me try . ( I did it before and got little difference, therefore did not this time ) thanks Taka
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
