Hi Derek,
I've added ath5k-devel list since I think it worth a public discussion.
Derek Smithies a écrit :
> 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.
Agreed. Let's not waster our time.
>
> 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.
I come up with something using 2 register reads and a third read when
needed. I'll send a patch for this. It has been tested for handler TSF
lower part rollover only (which is not so bad compared to the existing
code).
>
> 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.
OK. So let's say that between each register read, the following event
can happens :
- TSF lower part rollover
- TSF higher part rollover
- TSF has been reset
- TSF jumps (due to IBSS hardware merges). In this last case, we
consider it could happen only once during the whole register read sequence.
I'll try to study all cases on a piece of paper.
Regards,
Benoit
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
