Am 27.05.2011 08:40, schrieb Gilles Chanteperdrix:
> On 05/26/2011 07:28 PM, Jonas Witt wrote:
>> Hi all,
>>
>> i am having a problem concerning the clock drift under load:
>>
>> # /usr/xenomai/bin/clocktest
>> == Tested clock: 0 (CLOCK_REALTIME)
>> CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
>> --- -------------------- ---------------- ---------- --------------
>>     0          775571614.0       166776.858          0            0.0
>>
>>
>> It remains in the hundreds of MILLIseconds, changing constantly. My
>> setup consists of an embedded Intel Atom board (1.6GHz Z530 processor)
>> with a 2.6.32.7 kernel and Xenomai 2.5.2.
> Hi Jonas,
>
> Could you try and see if 2.5.6 with latest I-pipe patches has the same
> behaviour?
>
>> Latencies under load are
>> reasonable. Mean latency<  10us. Maximum latency<  40us.
>>
>> Without load the ToD offset is approximately constant over time with a
>> ToD drift in the range of 10 microseconds (strangely after a while this
>> settles in a range of 2 microseconds). Does anyone have an idea how this
>> can be caused?
> First, I am not sure clocktest is meant to be use under load. Second,
> does your system uses ntp?
>
>> As a workaround I currently use rt_timer_read() in all
>> relevant programs (also the non-realtime ones), since I need consistent
>> timestamps between realtime and non-realtime tasks.
> In order to solve this particular issue, we have a solution, but not yet
> in stable released versions.
>
>> One other (maybe unrelated) strange behavior is occasional secondary
>> mode switches when calling rt_queue_read(...).
> For this error, we need more details, such as a simple test case
> allowing to reproduce the issue, and again, you need to be sure to
> reproduce the issue on latest stable release with latest I-pipe patches.
>
> Regards.

Hi Gilles,

thanks for your input. I will try Xenomai 2.5.6 soon. In the meantime I 
wrote a simple load simulator to reproduce the issue with my more 
complex program. The clock drift only occurs with a load of more than 
30%. Below that the clock is fine. So you may have to adjust the 
attached code (e.g. change the 2000 value in the for-loop to something 
larger) to stress your system to that level where the processing time is 
more than 2000 microseconds.

Cheers,
Jonas