[LinuxPPS] ntptime status - relaunch of that issue

[Hal V. Engel]

On Thursday 05 March 2009 02:38:35 am Felix Joussein wrote:
> Big thank to all of you who have helped to track down the problem!
>
>
> The best results seam to run on an intel atom (330) with hped clocksource.
>
> Now there is one more little issue:
> 1. How do I get hped as default timer at boot time?

Add 

hpet=force

to your boot command.

> When booting my machine it's always tsc, which brings worse results.
> 2. An other issue is the time ntpd needs to come down to an offset of
> max 0.010 and an jitter of max 0.003.
> On my machine it takes about 4-5 hours...

I have added -g (--panicgate) to the list of parms that is used to start ntp.   
On my machine this is set in /etc/conf.d/ntpd but it may be different 
depending on what distro you are using.  What this does is forces a one time 
syncing of the system clock to the refclock (IE. a jump in the time) when ntpd 
is started.  I believe that by default this does not happen unless the clock 
is off by more than 128 milliseconds.  But I could be wrong about this and you 
can adjust this using the -x (--slew) switch.  

My clock usually drifts by more than 128 milliseconds during down times (like 
over night).  With --panicgate I start out with an offset < 50 microseconds 
(IE. 0.050 max) and things settle down to the 5 to 10 microsecond range in 
perhaps 15 or 20 minutes as the temperature of the machine stabilizes.  

In my book an offset of 50 microseconds means that my machine is a true 
stratum 1 machine almost as soon as ntp is running and has reached the 
refclock which takes less than a minute.  Also with --panicgate ntp will not 
report having reached the refclock until it has synced with it and made the 
initial larger time adjustment.

One other consideration.  If you have more than one server line in your ntp 
configuration and you have --panicgate set then ntp will sync the clock with 
which ever server it first connects with.  The concern is that you may want it 
to only sync to the local refclock but it may connect to one of the other 
(less accurate) servers first and use it to make this initial adjustment 
resulting in a larger initial offset than you want.

> it starts at about 40.000 /
> 0.800. The 4-5 hours wouldn't be that much of a problem,

This is what my machine was like before I started using ---panicgate when 
starting ntp.

> fare more the
> fact, that ntpd switches to stratum1 eventhought it's not as precise as
> desired... So the second question is: can I set a threshold which limits
> the
> stratum1 to a defined offset/jitter level?

I just did a man ntpd and didn't see anything.  The only threshold adjustment 
I saw was the slew/jump threshold that can be changed with -x or --slew.  But 
this will not do what you are asking about.  NTP is intended for time servers 
that are expected to run continuously so the design is not intended to cause a 
quick clock sync.  So it does have some issues on machines that are rebooted 
or have down time like a workstation/end user machine.   Your best bet is to 
try --panicgate.

> 3. Can I accelerate the time adjusting from the pps (offset/jitter) signal?

See above.

>
>
> 4. More hardware: has anyone of you experience with VIA C7 CPU's and the
> clocksource issue?
>
> 5. anybody at CeBIT that weekend?
> Regards,
>
> Felix
>
> Hal V. Engel schrieb:
> > On Tuesday 24 February 2009 02:52:23 am Felix Joussein wrote:
> >> Hello Michael,
> >>
> >> I have checked that the current clock source is tsc and that 3 different
> >> are available in total: tsc, acpi_pm and jiffies
> >
> > Have you enables HPET in the kernel config?
> >
> > Also many motherboards have spread spectrum oscillators with introduces
> > continuous variations into the frequency of the system oscillator.  This
> > is intended to reduce radio frequency interference by spreading the
> > spurious RF over a wider frequency range so that the MB can meet
> > regulatory requirements. But it can cause issues for accurate time
> > keeping.  In some cases the BIOS settings will allow you to turn off this
> > "feature" so it is worth the effort to check to see if you can do this.
> >
> >> I have changed them to see what happens:
> >>
> >> tsc & acpi_pm show no differences...
> >> jiffies let's the beeper beep permanently... as soon as the keyboard
> >> produces a short beep (for ex. backspace on begin of line)... and after
> >> setting jiffies you can't reset it to tsc (the echo tsc > /sys/.....) is
> >> useless... not exewcuted, because a cat of the file still shows jiffies.
> >>
> >> I also have compared the behavior  from my former 2.4 installation
> >> mentioned in my posts before, and realized, that the ntpd would not even
> >> start.
> >> In dmesg I get: many lines "do_clock_gettime: negative time wrap on
> >> CPU#0: -60751978ns (0,7646704)" and ntpd produces
> >> "adjtimex: ntpd could be using obsolete ADJ_TICKADJ" and then stops
> >> itself again.
> >>
> >> The ppstest equivalent in 2.4 is ppsctl, the output is pretty similar to
> >> ppstest, the jitter is bouncing from 640 to -32, -672, 704 per line.
> >>
> >> when I try to run ntpd -d I get a lot debugging output, and at the end a
> >> freezed screen. (So definitely this hardware s***ks, maybe I better turn
> >> it into a DVR device!)
> >>
> >> The current machines, running 2.4 kernel + PPSKit are Pentium III with
> >> 512MB Ram...
> >
> > The PIII has an invariant TSC counter and that would explain at least
> > part of it's good time keeping performance.
> >
> >> The Idea to use Pentium M's was to limit power usage.... the industrial
> >> PC I'm using now has a Pentium M and 2 GB RAM is using 80W at most...
> >> So: how about an Intel ATOM?
> >
> > Maybe but there was a long thread about TSC counters on the ntp mailing
> > list back in the time frame after AMD had announced their plan to make
> > future AMD CPUs TSC invariant and there appeared to be skepticism at that
> > time about Intel's offerings in this regard at least in part because the
> > feature was poorly documented.
> >
> >> So, what would be the recommended hardware setup?
> >
> > Another option might be to use one of the low power amd64 CPUs that was
> > recently released.  I know that one of these is rated at 9 watts (single
> > core, there is also a dual core unit rated at 22 watts) and with a low
> > power consumption MB chip set (AMD makes some of these) you should end up
> > with a system with very low over all power consumption that is in the
> > same ball park as an Atom system (the chip set used on the Atom MB has
> > fairly high power consumption and this is the chip with the big heat sink
> > on it) and you will almost for sure end up with a solidly implemented
> > invariant TSC.
> >
> > I should add that it is almost impossible to know how good any hardware
> > setup will work without first testing it.   But if I was building a new
> > system that was intended as a low power consumption time keeping network
> > appliance I would go with one of these low power AMD CPUs if for no other
> > reason than that the TSC features are well documented and were
> > specifically intended for time keeping.
> >
> >> thank's for helping me!
> >>
> >> regards,
> >>
> >> Felix Joussein
> >>
> >> Michael Meier schrieb:
> >>>> I played around with different hardware and realised, that then faster
> >>>> a machine is, then less the offset / jitter is.
> >>>> For example on an amd64 X2 5000+ jitter/offset is about 0,100 - 0,010
> >>>> +/- while with the Pentium M processor the offset/jitter rises up far
> >>>> beyond 1,000...
> >>>> I think, the Pentium M (1700MHz) should be way enough for a ntp
> >>>> server?
> >>>
> >>> The CPU Power surely is enough, but you might hit an architectural
> >>> problem with the Pentium M: It has a timestamp counter [1] that does
> >>> NOT increase monotonically, even when all power saving features are
> >>> disabled. Since the TSC is the default and preferred timesource of the
> >>> kernel, that will cause some confusion. The kernel will detect that
> >>> the TSC is crap after some time, and switch to another source after
> >>> some time if it has some available, but the TSC really is the best you
> >>> can get. The only thing that comes close to it is HPET (High Precision
> >>> Event Timer), and that is not available everywhere. And naturally, if
> >>> ntpd cannot get the local time from the kernel with a sufficiently
> >>> high resolution, things will start to jitter.
> >>> You should check what your kernel currently uses as timesource (cat
> >>> /sys/devices/system/clocksource/clocksource0/current_clocksource), and
> >>> what sources it has available
> >>> (/sys/devices/system/clocksource/clocksource0/current_clocksource).
> >>> You can also check in the kernel logs, the kernel usually tells you
> >>> when it changes the timesource and why.
> >>>
> >>> [1] http://en.wikipedia.org/wiki/Time_Stamp_Counter
> >>
> >> _______________________________________________
> >> 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