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

[Sebastian Smolorz <smolorz@domain.hid>]

Jan Kiszka wrote:
> Cornelius Köpp wrote:
>> Hello,
>> I run the latency test from testsuite on several hard and software 
>> configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results 
>> shows a "strange" behavior: In Kernel mode (-t1) the latencys 
>> constantly linear decrease. See attached plot 
>> 'drifting_latencys_in_kernelmode.png' of latency test running 48h on 
>> Pentium3 700. This effect could be reproduced, even on other hardware 
>> (Pentium-M 1400).
> 
> As our P3 boards did not support APIC-based timing (IIRC), your kernel 
> has correctly disabled the related kernel support. But the Pentium M 
> should be fine. So could you check if we are seeing some TSC clocks vs. 
> PIT timer rounding issue by enabling the local APIC on the Pentium M?

There is no difference in enabling the local APIC on the Pentium M WRT 
this bug.

>> The usermode (-t0) did not show a drifting, but is influenced by a 
>> test ran in kernelmode before.
> 
> What do you mean with "is influenced"?

Cornelius saw the following behaviour: If the latency test was run in 
user space first, no drift appeared over time. If latency was run in 
kernel space (with the reported ngeative drift) a following latency test 
in user space showed also negative values but with no additional drift 
over time.

>> I talked with Sebastian Smolorz about this and he builds his own 
>> independent kernel-config to check. He got the same drifting-effect 
>> with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several 
>> hours. His kernel-config ist attached as 
>> 'config-2.6.24-xenomai-2.4.3__ssm'.
>>
>> Our kernel-configs are both based on a config used with Xenomai 2.3.4 
>> and Linux 2.6.20.15 without any drifting effects.
> 
> 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.

-- 
Sebastian