Re: [Xenomai-help] Huge clock drift

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

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

On 2011-05-29 00:08, Gilles Chanteperdrix wrote:
> On 05/28/2011 04:32 PM, Jan Kiszka wrote:
>> On 2011-05-27 21:11, Gilles Chanteperdrix wrote:
>>> On 05/27/2011 08:29 PM, Jonas Witt wrote:
>>>> Sorry, I missed the NTP-part. I am not using NTP. Just plain timer 
>>>> queries on a single system.
>>>>
>>>> My clock source is tsc which is the same for Xenomai I suppose.
>>>>
>>>> I wonder how a Xenomai task, even if it occupies 50% or even 90% of a 4 
>>>> milliseconds time slice can interfere with the tsc. The tsc is not 
>>>> incremented via an interrupt, is it? But I do not know much about the 
>>>> inner workings of these functions.
>>>
>>> The problem is not the clocksource, the problem is the timer interrupt.
>>> The kernel expects 1 timer tick every millisecond.
>>
>> Not on archs that are CONFIG_NO_HZ capable.
> 
> Last time I looked at CONFIG_NO_HZ, it did not look as Xenomai one-shot
> timer at all. The system still had a periodic timer ticking HZ times by
> second, in order to handle the non-high resolution timers. And this
> timing was entirely disabled only when the system was idle. So, in other
> word, the Linux kernel still needed a periodic timer interrupt.

Linux (with some architectural exceptions) no longer needs high-rate
timer ticks for time keeping. Of course, if you miss timer events due to
high Xenomai activity (or overload of the host machine when running as a
VM), that's not good for reactivity and may have other side effects.

> 
>>
>>> When you run a
>>> real-time task during 2 milliseconds and prevent the kernel from
>>> receiving the timer interrupts, you certainly disrupt its timekeeping.
>>> If you want to do this, switch the Linux kernel frequency (CONFIG_HZ) to
>>> 100.
>>
>> Time keeping can perfectly bridge a lot of missing ticks as far as the
>> underlying clocksource allows. And that's quite a bit with the x86 TSC.
> 
> Here, we are asking it to only receive one interrupt over two. I have to
> admit that I talked without testing, but as long as we do not test the
> kernel behaviour in order to test whether it allows such disruption, I
> find it safer to advise people not to disrupt it.

I'm not suggesting people can now safely write RT hogs. But I don't
think the overload scenario here should be responsible for the clock drift.

Jan


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