hi!
i think we don't need to worry too much about one or two register reads more
or less. (in my tests on a pretty slow board, one TSF register read needed
about 1,3us in average thru 1000 reads).
also i can reproduce the wrap problems here on a 5414 chip.
the HAL has a 3x read approach, so we definetly have to do something...
we could avoid the problem of being interruped locally by disabling interrups
(local_irq_disable())...
but what we cannot avoid are the HW merges, which could happen any time. so i
guess something like the loop approach derek mentioned could be the safest way
- but only checking the upper part is not enough. what happens if the HW
merge only updated the lower 32 bits (which should happen more commonly by
small automatic TSF adjustments)?
bruno
On Monday 01 March 2010 06:50:39 Derek Smithies wrote:
> Hi,
>
> On Sun, 28 Feb 2010, Benoit PAPILLAULT wrote:
> > So, there is no latch behavior IMHO. This test has been run with an
> > AR2425 minipci-e card.
>
> yes. it is possible that some cards have latch behaviour - and others
> don't. Which means we could initiate a tedious set of experiments to find
> which latch, and which don't. Such an effort would give us minimal gain.
> In fact, the gain would not be worth the pain&effort.
>
> I did some work on timing the madwifi get_tsf64 routine, and measured it
> to take 4 microseconds ( I did a million calls, looked at the value of
> tsf64 pre and post, and divided the answer). From looking at the released
> hal from Atheros (thanks for this code), we can "guess" that the hal I
> used in my timing does 2 register reads, and the madwifi code of locking
> etc, so a simple minded estimation suggests each register read takes 2us.
>
> My plan of read high, read low, read high, and possible read of low
> will take
> 3 register reads (6us)
> Since roll over occurs 4.3 thousand seconds and assuming 50 reads per
> second, then we can say,
> once in every 200 thousand reads, it will be 4 register reads.
>
> Indeed, looking through your results does suggest a similar time to read
> the TSF registers.
>
> >> I changed the ath5k_hw_get_tsf64 to consist of three reads.
> >> h1 = get high register
> >> l = get low register
> >> h2 = get high register
> >> if (h1 == h2)
> >>
> >> return h1| l
> >>
> >> return h2 | (get low register);
> >>
> >> and the wrap reports disappeared.
> >
> > Do you think there is a way to achieve the same result and avoiding 4
> > register reads instead of 2 ? I think about checking the low register
> > against very high or very low value for instance ... or keeping track of
> > the previous tsf read, since it should be ever increasing...
>
> it is doable, yes, but the effort required to get it right is
> considerable. Some will argue that the extra effort in tracking the
> previous TSF value will minimise the saved time in reading the TSF.
>
> My vote is with the three register read approach, as it is simple, clear
> and succinct.
>
> Any approach you take has to be resilient to the following events
>
> read TSF (2 register read, as part of normal operation)
> TSF jumps because of hardware merge
> - our software does not see these events
> read TSF (2 register read, as part of normal operation)
>
> The second read of the TSF may decide the high register has changed
> (because of the TSF merge), and will then do an additional read. But
> what happens if there is a 32 bit wrap during the additional read?
>
> Hmm, still a problem. What happens if there is a merging of the hardware
> TSF during my proposed three register read? We know that the merges don't
> happen "frequently", and I cannot expect two merges to happen in 10us of
> each other. (the tramsmit time of packets is much longer than 10us)
>
> int loop_counter = 0;
> do {
> read h1
> read low
> read h2
> if (h1 == h2)
> return h2 | l
> loop_counter++;
> } while (loop_counter < 3)
>
> assert here - bad things have happened.
>
> Most often (99.9% of the time) it does the loop once.
> it is only in exceptional circumstances would it need to loop twice.
> In very very rare circumstances (99.99999%) it would loop three times.
>
> In very very very very rare circumstances it would get to the error place,
> which is only caused by hardware issues - and radio operation is clearly
> broken if it gets to here. In which case, failure is the only path way.
>
> Derek.
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
