Gilles Chanteperdrix wrote:
> On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka <[EMAIL PROTECTED]> 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
Xenomai-core mailing list