On 22 May 2015 at 19:11, Srinivasa Duvvuri <[email protected]> wrote:
> Michal,
> Sorry I was out sick last few days. Thanks for splitting and creating 2
> patches.
> The math for total cycle counts makes sense but the math to handle the
> rx_clear_count
> does not seem right to me. For the total cycle count we know that the
> count changes
> from 0xffffffff to 0x7fffffff. So, we clearly know the wrap around point
> . But for
> rcc( rx_clear_count) we do not know when this count is halfed (wrapped).
>
> Lets say rcc_prev is the previous clear cycle count, rcc is the current
> clear cycle count
> and rcc_wrap is a point at which the the total cycle count is wrapped
> from 0xfffffffff to 0x7fffffff .
> At that point the rcc_wrap resets to rcc_wrap/2.
>
> Here is how counts wrap around.
>
> cc_prev ............0xffffffff -> 0x7fffffff ................ cc
> rcc_prev ............rcc_wrap -> rcc_wrap/2 ........... rcc.
>
> The right math to calculate rcc_delta would be (rcc_wrap - rcc_prev) +
> (rcc - rcc_wrap/2).
> To do the math, we need the rcc_wrap which we do not have.
> the patch seems to simply do 2*rcc - rcc_prev . Unless I am missing
> something,
> this does not seem right to me.
Ah, you're right. I guess I'll need to discard the data like you
originally did upon wraparound detection.
Michał