2007/12/18 bruno randolf <[EMAIL PROTECTED]>:
> On Tuesday 18 December 2007 01:24:07 Nick Kossifidis wrote:
>> 2007/12/17, bruno randolf <[EMAIL PROTECTED]>:
>> > hi nick!
>> >
>> > thanks for the explanations, that makes it a bit more transparent how you
>> > figure that stuff out...
>> >
>> > On Monday 17 December 2007 15:02:05 Nick Kossifidis wrote:
>> > > Bruno can you redo this dump with 802.11b link (CCK) ? It might be
>> > > easier to spot what these registers do (and verify if i'm right about
>> > > the part that disables ofdm weak signal detection).
>> >
>> > sure! here you go:
>> > http://br1.einfach.org/ath/ani2.tgz
>> >
>> > - traces of a 5212 in b and g mode. it also includes traces from 5414 in
>> > all modes (a, b, g). all done in adhoc mode using the current HAL
>> > (0.9.30.13).
>> >
>> > please bear in mind that turning ANI on and off has resulted in different
>> > experiences in different setups: turning it *off*, i.e. no ANI has been
>> > reported to work very well and improve thruput in point-to-point links in
>> > a countryside environment, and also in my lab tests using 2 nodes next to
>> > each other thruput increases (11M -> 20M).
>> >
>> > other people report that turning ANI *off* results in bad performance in
>> > urban and multihop environments, especially with omnidirectional
>> > antennas. that kind of makes sense, but it's not really clear (yet?) what
>> > the other factors are. in any case it would be good to have the option to
>> > use ANI or not.
>> >
>> > bruno
>>
>> Dumps are the same for b and g, did you use iwpriv ath0 mode 2 to force b
>> mode ?
>
> hi nick!
>
> interresting, the dumps for 5414 b/g don't differ in the relevant parts
> ('5414_new_adhoc_b.txt' and '5414_new_adhoc_g.txt') but the ones for 5212 do
> differ, imho ('new_adhoc_b.txt' and 'new_adhoc_g.txt'). i just re-did the
> 5414 dumps, with the same results, to make sure i didn't make a mistake. of
> course i used iwpriv ath0 mode 2 to force b mode.
>
> bruno
>

Hello ppl ;-)

I have some code for you to test with some initial ANI support, i 'm
sure i miss something because it doesn't work after this (no rx)
http://www.kernel.org/pub/linux/kernel/people/mickflemm/ath5k-ani.tar.bz2

Known bugs:

a) On non-5212 hw it'll result a segfault because i don't check for
chip version durring ani_reset but i do check durring attach (well
most of you have 5212 chips so you won't hit this i guess).

b) During attach i do a bad memory allocation
ani_stats = kzalloc(sizeof(struct ath5k_ani_state), GFP_KERNEL);
just change it to
ani_stats = kzalloc(sizeof(struct ath5k_ani_stats), GFP_KERNEL);

problem seems to be in the initial settings used, i'm working on it
but the more people they check it out the faster we can make it work
;-)

algo is the one described in the patent doc, not the one used on ath9k

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to