[LinuxPPS] still some offset and jitter though using pps

[Hal V. Engel]

On Monday 20 October 2008 01:59:21 Nicola Berndt wrote:
> Nicola Berndt schrieb:
> > Btw, things have settled down now (after half a day) to an offset of
> > 0.970 and a jitter of 0.017.
>
> So I monitored things over the weekend and found it to behave nicely,
> values for offset and drift were always somewhere in the 0.0xy range. So
> once it has settled down my hard-/software combination can actually do a
> good ntp-job.

Having your offset and jitter be <100us is not particularly good for a GPS 
driven ntp machine.  When my system is stabilized and running at a stable 
temperature and low load I expect the offset to be <10us and to be <5us much 
of the time and the jitter to be 2us or lower all of the time.

>
> Still the startup problem resides: Just now I changed my timepulse from
> 100 to 200 ms 

Any pulse length longer than your kernel tick interval should be fine.  At 
100Hz this is 10ms.  So I would not expect changing this from 100ms to 200ms 
to make any difference.

> but still after starting up, the offset grows way over 200
> and takes very long to find its way back. This happens with and without
> driftfile.

What do you do to sync the clock to UTC at system start up?  Your system clock 
will drift while the machine is powered down and I have found that syncing the 
clock to an external ntp stratum 1 server before starting ntpd gets my clock 
offset below 3ms at start up and ntpd will take the offset down below 100us in 
a half hour or so and within 2 hours it is below 10us.  Also keep in mind that 
ntp is optimized for time servers that are continuously running and it is not 
designed to instantly bring the clock into sync with UTC after start up 
although it might be possible to configure it so that it brings the clock into 
sync more quickly.

> The driftfile also has a noticeably high value of almost 400
> and is being rewritten with similar high values after its deletion.

In general the oscillators used on computer motherboards are of very low 
quality.  Cheap quartz wrist watches will generally have much higher quality 
oscillators.   Most computer motherboard vendors are buying the cheapest 
oscillators they can find to keep manufacturing costs low.  These oscillators 
can vary significantly even with in the same production run and in some cases 
can have a huge impact on the time keeping ability of the computer.  This web 
page http://www.ijs.si/time/#platform has more information on how to evaluate 
the quality of the oscillator in your computer.  In particular he says "Aim 
for a platform with a relative frequency below roughly 20 or perhaps 50 ppm."  
Your machine is around 400 ppm which is approaching the limits of what ntp can 
handle and this in an indication that there may be issues with the quality of 
the oscillator in your machine.    He also has a section on how to evaluate 
the temperature dependency of the oscillator.  I suspect that some of the 
issues you are seeing are because your oscillator is not very stable and that 
it's frequency changes significantly as the computer warms up.  This could 
also indicate cooling/temperature control issues with the machine or that the 
oscillator is in a location that results in large temperature changes as the 
machine warms up.

>
> My kernel is a preembile kernel, timer_frequency is configured to 100 hz
> and I don't have a tickless system 

This is the correct setting  for these and this is what I am using.

> nor high resolution timer support
> enabled. 

But I do have high resolution timer support turned on.  I don't know what 
impact this has but I think I remember reading someplace that this should be 
enabled for ntp.

> I also tried the different available clocksources on the kernel
> command line but that didn't help. Strangely clocksource acpi_pm is not
> available under
> /sys/devices/clocksource/clocksource0/available_clocksource , only tsc,
> pit and jiffies.
>
> So for now that is as much information as I can give.
> What really puzzles me, ist that the system can obviously keep a stable
> and precise time. How comes, it drifts off so badly right after startig
> up and needs so long to come back? Could anyone please explain that to me?

See the oscillator comments above for some ideas.

Hal