On Wednesday 03 March 2010 11:46:59 Derek Smithies wrote: > On Wed, 3 Mar 2010, Bruno Randolf wrote: > >(can we say that ath5k hardware is crap for IBSS?). > > No - one cannot prove that ath5k hardware is crap in IBSS until you can > demonstrably show that all parts of the driver are correct.
agreed, but there are definetly design flaws in the hardware, which makes implementing IBSS very difficult. come on there are the problems (we have even tried to debug together in the last years), which are definetly hardware problems related to IBSS - ATIM, TSF jumps, timer configuration... > yes, but you do need to correctly read the TSF. even with code (loops, etc) in place to correctly read the TSF one time, a HW merge might happen immediately after that, so all timer configurations may go wrong anyways. also we cannot trust the extended RX timestamps (which are used to check for IBSS merge), since the part in the descriptor (15bit) may be from before a HW merge and the TSF from after. combining them will result in nonsense. > I did a test (admitedly > with madwifi, but the results may hold) that if the calculated tbtt time > is wrong (too large or too small) then that particular node never sends > out beacons, and so merging is "problematic" sure, i know that problem. > - have you done a test with ath5k where the calculated tbtt value is > wrong - what happens? yes i have seen that - and added code to update the timers in cases we can detect a HW merge. see ath5k_check_ibss_tsf() in base.c. all i'm saying is that as it stands we can not trust the TSF and the timestamps 100% no matter what we do in software. we have to find ways to work around that as good as possible. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
