Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

[Sebastian Smolorz <smolorz@domain.hid>]

Gilles Chanteperdrix wrote:
> On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Sebastian Smolorz wrote:
>>  > Jan Kiszka wrote:
>>  >>
>>  >> 2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
>>  >> not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
>>  >> values (that naturally show up when the system runs for a longer time).
>>  >
>>  > This hint seems to point into the right direction. I tried out a
>>  > modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old
>>  > implementation in include/asm-generic/bits/pod.h was used. The drifting
>>  > bug disappeared. So there seems so be a buggy x86-specific
>>  > implementation of this routine.
>>
>>  Hmm, maybe even a conceptional issue: the multiply-shift-based
>>  xnarch_tsc_to_ns is not as precise as the still multiply-divide-based
>>  xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we
>>  may loose some bits, maybe too many bits...
> 
> If you want to know whether llmulshft implementation is broken on x86
> or if there is a design issue, you can attempt to use the generic
> implementation on x86.
> 

You mean not using rthal_llmulshft() in arith_32.h and instead using 
__rthal_generic_llmulshft()? I tried this and it's also suffering from 
the drift although it seems that the drift per time unit is smaller in 
the generic case. I will try to get some numbers to compare the values 
returned from rthal_llmulshft(), __rthal_generic_llmulshft() and 
__rthal_generic_ullimd().

-- 
Sebastian