> If no ntp server updates are made to the Linux clock, we have
> noticed over a week's period a drift of ten or so seconds difference
> between the Linux clock and the Xenomai get time function and often
> have to reboot our machine to resynchronize the Xenomai and Linux
> clocks back to less than a couple seconds difference. I was
> wondering if you might explain why that might happen?
Your clock oscillator on the x86 PC is drifting wrt NTP time (the
oscillators are known to be bad time sources). We see the same effect
here. With NTP running, try running a RT periodic thread and obtain both
Linux system time and Xenomai RT time. You will see a sawtooth time
difference reaching around 1msec in magnitude before NTP readjusts Linux
system time back down to near zero. Then the clocks drift wrt one
another until you have around a 1msec difference, and NTP adjusts the
time again. I recall a periodicity of around 30-60sec per adjustment
cycle (5-10 seconds per week) but it is dependent on the characteristics
of your specific oscillator on the motherboard.
I have thought to cope with this by having a rate parameter on the code
encapsulating my timing source (I have "drivers" for Linux system time,
Xenomai time, and hardware timing sources). The NTP rate in the drift
file is pretty constant, so one could presumably use that rate to adjust
your timers.
hth
- Tom
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
