Re: [Xenomai-core] [PATCH-STACK] Updates, timerstats, rtdm-timers

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> Jan Kiszka wrote:
>>> ...
>>>
>>>> fast-tsc-to-ns-v2.patch
>>>>
>>>>    [Rebased, improved rounding of least significant digit]
>>> Rounding in the fast path for the sake of the last digit was silly.
>>> Instead, I'm now addressing the ugly interval printing via
>>> xnarch_precise_tsc_to_ns when converting the timer interval back into
>>> nanos. -v3 incorporating this has just been uploaded.
>>>
>>
>> After noticing yesterday that even unpatched Xenomai sometimes converts
>> inaccurately when showing small timer intervals under /proc, I just got
>> an idea how to address this beautification issue even better: -v4 now
>> rounds up in the slow, precise tsc-to-ns path, see
>>
>> http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/fast-tsc-to-ns-v4.patch
> 
> I am the one who decided of the rounding behaviour of llimd, RTAI
> version had the same rounding policy as the one you propose, and I made
> it for the following reasons:
> - rouding towards 0 is the policy used by the C language, so doing this
> for llimd made it consistent with what one expects from C code;
> - values computed by llimd are used to program timers, and we prefer the
> timer to be programmed for a too short value than for a too long value.

That's OK, I agree. In my patch for i386, this rounding is only relevant
for display purposes. It's just to help me finding the expected period T
of my task in /proc instead of T-1 sometimes. Beautification. All we
need for other archs is xnarch_tsc_to_ns according to the old scheme.
Will rework this.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]