[LinuxPPS] ntpd synchronization issues

[Hal V. Engel]

On Sunday 08 August 2010 10:49:42 am Felix Joussein wrote:
>   What if I disable ACPI in the kernel?

I don't know if that would do anything.  To many variables - kernel version, 
modules loaded, motherboard hardware... - to know for sure how any one thing 
will affect timekeeping.  Since an ACPI module did have a very bad impact on my 
machine I think it is worth trying but at best it is a shot in the dark.

You might also have a look at what counter you are using.  On most of the 
architectures you have used the TSC counter is not invariant and if your 
system is defaulting to the TSC counter timekeeping will not be good.    So 
you should query your system to see what counter is it using (if for no other 
reason than so that you know) and then try some others.  For machines that are 
not TSC invariant the HPET timer/counter, if you have one, is probably the 
best one to use.  You may have to enable the HPET timer in the kernel config 
and you may have to force it's use during boot up.  As a side note it appears 
that the ACPI PM timer is based on the TSC counter.

> 
> Am 2010-08-08 19:37, schrieb Hal V. Engel:
> > On Sunday 08 August 2010 09:55:08 am Felix Joussein wrote:
> >>    Hi Udo,
> >> What kernel version?
> >>
> >> Current Stable (2.6.34)
> >>
> >> What ntpd version?
> >>
> >> The source, which is shipped with Ubuntu 10.04 which is 4.2.4p6.
> >> I build the source using: --enable-all-clocks --enable-ATOM
> >> --enable-parse-clocks --enable-accurate-adjtime --with-crypto
> >>
> >> What refclock?
> >>
> >> here's my ntp.conf:
> >>
> >> # refclocks
> >> server 217.19.37.20 iburst minpoll 4 maxpoll 4 prefer
> >> server 217.19.37.26 iburst minpoll 4 maxpoll 4 prefer
> >> server 217.19.37.27 iburst minpoll 4 maxpoll 4 prefer
> >>
> >> # PPS0
> >> server 127.127.22.0 iburst minpoll 4 maxpoll 4 prefer
> >> fudge  127.127.22.0 stratum 0 refid ATOM flag3 1
> >>
> >> # PPS1
> >> server 127.127.22.1 iburst minpoll 4 maxpoll 4 prefer
> >> fudge  127.127.22.1 stratum 0 refid ATOM flag3 1
> >>
> >> driftfile /var/lib/ntp/ntp.drift
> >> keysdir /etc/ntp
> >> crypto randfile /var/lib/ntp/.rnd
> >> crypto pw leapsecreet
> >>
> >>
> >> Any patches for kernel or ntpd?
> >>
> >> Kernel: No
> >> ntpd: probably the Ubuntu patches
> >>
> >>
> >> But: I have had the same problem over the last year with kernel versions
> >> prior to 2.6.34 and ntpd source from ntpd.org
> >> So far I used this hardware:  Intel Atom N330, N270, N510, IC2, AMD X2,
> >> AMD Geode, VIA Eden
> >>
> >> regards,
> >>
> >> Felix
> >
> > I am running AMD X2 hardware with an ASUS motherboard.  My system would
> > sync the time fairly quickly with kernels before 2.6.28 then it started
> > syncing very slowly.  Some patches to the kernel where posted here that
> > fixed this problem and these became part of the main line kernel starting
> > with 2.6.30 (I think).  I am now running un-patched gentoo-sources 2.6.34
> > which I upgrade from 2.6.28 and it syncs quickly and is down below 5 us
> > offsets in perhaps 15 minutes give or take.
> >
> > The 2.6.34 kernel did introduce another timekeeping related issue for me
> > however.  Starting with 2.6.32 the kernel was changed so that it requires
> > a new kernel module to do hardware monitoring on some motherboards
> > including mine.  Because of this I should now be using the ATK0110 module
> > to get hardware readings using the ACPI interface (rather than lm_sensors
> > directly poking the sensor hardware).  Without this module lm_sensors no
> > longer works fully (no motherboard temperatures, voltages or fan speeds).
> >  But with the ATK0110 module loaded ntp does not sync and time keeping is
> > horrific.  I have opened a bug report on kernel.org about this but so far
> > nothing has happened. Currently I do not have lm_sensors working fully on
> > my machine.  My point is that how the kernel is configured and what
> > modules you load can have a huge impact on time keeping and the ATK0110
> > module on MY HARDWARE is an example of this.  But it is also one I
> > discovered by dumb luck and if I hadn't first had time keeping working
> > nicely with 2.6.34 initially and then tried to fix the new lm_sensors
> > problem I would not have known the cause of the timekeeping problem.  But
> > it is clear that at least on some hardware the kernel ACPI modules can
> > cause timekeeping issues and there may be other modules that impact
> > timekeeping as well.
> >
> >>>> So my question is rather simple: Do you also have this problem?
> >>>
> >>> No... I did not measure time to get down to 0.00xxx but it is quick
> >>> enough.
> >>>
> >>>> Which distribution did you use?
> >>>
> >>> Fedora. But I compile ntpd and kernel.org myself.
> >>>
> >>>> Which hardware is the best?
> >>>
> >>> What demands do you have for the precision?
> >>>
> >>> Udo
> >>>
> >>> _______________________________________________
> >>> LinuxPPS mailing list
> >>> LinuxPPS at ml.enneenne.com
> >>> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> >>> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
> >>
> >> _______________________________________________
> >> LinuxPPS mailing list
> >> LinuxPPS at ml.enneenne.com
> >> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> >> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
> >
> > _______________________________________________
> > LinuxPPS mailing list
> > LinuxPPS at ml.enneenne.com
> > http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> > Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
> 
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>