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

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

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

Jan Kiszka wrote:
> 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.

Done, -v5 is online.

This is not yet incorporating any change to the generic llmulshft. I
haven't thought about nor tried our code on a 64 bit arch yet. Did you
check this already? I wonder, eg., if it makes sense to exploit 128 bit
with 64 bit shifts there or stick with 94/32 bit accuracy and related
conversion errors. Depending on this, the generic version might have to
be reconsidered.

Jan


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