On Wed, 3 Mar 2010, Bruno Randolf wrote:
> 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.
They may not be flaws - just documentation issues. - or our understanding
of the importance is not enough.
> 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...
TSF jumps - yeah I looked into that on madwifi. For no apparent reason,
the TSF would jump to stupidly high values (hundred thousand years). After
chasing all the possible reasons on madwifi, I found that if you do the
script
while true; do iwpriv ath0 debug_athreset 1; sleep 10; done
and leave it running for a couple of hours, the TSF would jump to
unreasonable numbers. Who knows why? There is no code in the hal or
madwifi driver for adjusting the TSF - so why does it go up to such
stupidly high values?
It was in the process of looking for the cause of the jumps that I found
the TSF reading issue that is the core of this email thread.
You have to do
read h1, read low, read h2
if h1==h2, then return (h2<<32)|low
This will work 99.99% of the time
read l2, h3
if h3 == h2, then return (h3<<32)|l2;
This will work 99.999999% of the time
read l3, h4
if (h4==h3), then return (h4<<32)|l3
This will work 99.99999999999% of the time, which is 100 %
I cannot think of a mechanisim of merge/rollover/merge that will beat a
loop of three. To be safe, 6 cycles. Who cares ? The cost of this extra
code is minuscle. there is no extra cpu penalty. Since most of the time
(99.99% of the time) there is only 3 reads, at an average of 2us per read,
so what?
> 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.
yes, but we can minimise the impact of HW merges on our calculated TSF value.
=========================================
> 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.
We don't need to use the RX timestamps to get the beacons in sync. The RX
timestamps are not required, and may (as you say) be misleading.
When we (in adhoc) calculate the next beacon transmit time, we
have three pieces of information
1)Beacons are (according to the spec) transmitted at (n*Bintval) + delta
(delta, random number, typically 500 us. n is an integer)
2)we know the TSF value in the received beacon we are merging to
3)we know that the hardware has already done the merge of TSF, so that the
TSF on the receiving box is the same as the TSF of the incoming beacon.
We can test that our hardware has merged to the TSF of the incoming
beacon, by comparing our hardware TSF with that of the TSF in the beacon.
We need to calculate the tbtt time to be (n+1)*Bintval
Calculating the next tbtt relative to the receive time stamp is wrong,
cause that includes the delta value.
If our hardware TSF is seconds ahead of the TSF in the incoming beacon,
there has been an additional hardware merge, and there is a beacon we are
about to process with a more recent TSF that we will merge to.
==============================================
> 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.
Absolutely.
So we have to make the most of the available information and do the right
thing as often as possible. We have to avoid doing the wrong things.
Derek.
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"The only thing IE should be used for is to download Fire Fox"
"My favorite language is call STAR. It's extremely concise. It has
exactly one verb '*', which does exactly what I want at the moment."
--Larry Wall
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
