NTP and PPS calibration interval (convergence speed)

[Miguel Gonçalves]

Hi!

I've read a lot about the speed of NTP when reacting to changes in
temperature to in turn affect the oscillator.

I am posting my findings and thoughts to the list so it becomes
archived for future users in need of this information.

First, let me say that I have 2 GPS receivers (Garmin 18 LVC -
10.0.2.2 - on the roof and Sure GPS board - 10.0.2.4 - on a window
facing South) connected to identical (both ALIX 1D boards) and
dedicated machines just for NTP. I am running 4.2.6p5 on both. I also
have a Meinberg NTP server (10.0.2.1) in the same LAN segment. This
configuration gives me 3 clocks one of which (Meinberg) I use to check
the performance of the others.

The 3 servers use minpoll 4 maxpoll 4 for their refclocks and each one
lists the other two as servers with minpoll and maxpoll set to 4.

For me, it is not clear why calibration occurs every 256 seconds when
I have a GPS receiver with a PPS output. I understand that a good
frequency drift estimation would be good when free running but frankly
I don't want my NTP servers to serve time when the GPS signal is not
available. I can trust my Meinberg box to do that because it has a
TXCO but not my regular NTP servers.

I was also surprised that Meinberg's NTP server calibration interval
never goes above 4 seconds. They must have done what I did.

I changed my FreeBSD 8.3 kernel to never go above 4 seconds and the
results are in the graphics attached.

I changed PPS_FAVGDEF in the file /sys/kern/kern_ntptime.c from the
default 8 (256 seconds) to 2 (4 seconds). The frequency is therefore
adjusted every 4 seconds instead of 256.

Here are some ntpq billboards


(Meinberg NTP server)

freebsd8# ntpq -p 10.0.2.1
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 12 16 377 0.000 0.000 0.002
+GENERIC(0) .GPS. 0 l 14 16 377 0.000 -0.001 0.002
oPPS(0) .PPS. 0 l 1 16 377 0.000 -0.001 0.002
-10.0.2.2 .PPS. 1 u 4 16 377 0.162 -0.005 0.011
+10.0.2.4 .PPS. 1 u 10 16 377 0.158 -0.003 0.006


(Garmin 18 LVC on the roof)

freebsd8# ntpq -p 10.0.2.2
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(0) .PPS. 0 l 11 16 377 0.000 0.000 0.004
+10.0.2.1 .PPS. 1 u 8 16 377 0.148 0.004 0.005
+10.0.2.4 .PPS. 1 u 7 16 377 0.132 -0.003 0.004


(Sure GPS board on the window)

freebsd8# ntpq -p 10.0.2.4
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(0) .PPS. 0 l 13 16 377 0.000 0.000 0.004
+10.0.2.1 .PPS. 1 u 10 16 377 0.161 0.004 0.006
+10.0.2.2 .PPS. 1 u 9 16 377 0.139 0.002 0.004



Hope this helps someone.

Regards,
Miguel

[David Woolley]

Miguel Gonçalves wrote:

>
> For me, it is not clear why calibration occurs every 256 seconds when

I don't understand what you mean by this, and I don't see any evidence
of a 256 in your posting.

> I have a GPS receiver with a PPS output. I understand that a good
> frequency drift estimation would be good when free running but frankly
> I don't want my NTP servers to serve time when the GPS signal is not
> available. I can trust my Meinberg box to do that because it has a
> TXCO but not my regular NTP servers.

The way to do this is to set tinker dispersion on the server, to reflect
a realistic worst case clock frequency error, and set tos maxdist, on
the clients, to represent how large an error margin you are prepared to
accept.

>
> I was also surprised that Meinberg's NTP server calibration interval
> never goes above 4 seconds. They must have done what I did.
>
> I changed my FreeBSD 8.3 kernel to never go above 4 seconds and the
> results are in the graphics attached.

comp.protocols.time.ntp is not a binaries newsgroup. I believe the
mailing list imposes similar restrictions.

>
> I changed PPS_FAVGDEF in the file /sys/kern/kern_ntptime.c from the

No such file in the source distribution, at least not for 4.2.7p333. No
such symbol in the ntpd sources.

> default 8 (256 seconds) to 2 (4 seconds). The frequency is therefore
> adjusted every 4 seconds instead of 256.

I'm going to guess it has something to do with the averaging time for
the frequency. Generally a longer averaging time will give you a more
accurate frequency, assuming that phase measurement error noise
dominates, which should be true below the Allan intercept.
Unfortunately, your Allan intercept may be exceedingly low and
statistically poorly behaved.
>

[unruh]

Not really. What would be more helpful would be graphs of the behaviour,
of the offsets over time, including times when the machines are heavily
used and times when they are not. (See for example
www.theory.phsyics.ubc.ca/chrony/chrony.html and past graphs as well)
Unfortunately the gps attached to my one ntp machine has gone nuts
(Garmin 18-- both my Garmins failed after about about 2 years. Not a
very good piece of gear-- but you can look at older graphs from 3 or 4
years ago to see how the ntp run machine behaved.
On 2013-05-24, Miguel Gon?alves <miguel.barbo...@gmail.com> wrote:
> --089e011847fa6181fe04dd73ae03
> Content-Type: text/plain; charset=ISO-8859-1

> --089e011847fa6181fe04dd73ae03
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> --089e011847fa6181fe04dd73ae03--
>

[Miguel Gonçalves]

On Tue, May 28, 2013 at 8:55 AM, David Woolley
<da...@ex.djwhome.demon.invalid> wrote:
> Miguel Gonçalves wrote:
>
>>
>> For me, it is not clear why calibration occurs every 256 seconds when
>
>
> I don't understand what you mean by this, and I don't see any evidence of a
> 256 in your posting.

There isn't because I did not post it. Calibration interval is not
polling interval.

# ntptime
ntp_gettime() returns code 0 (OK)
time d550e438.3dc51d94 Wed, May 29 2013 20:31:52.241, (.241289477),
maximum error 1739 us, estimated error 1 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 0.226 us, frequency 147.458 ppm, interval 4 s,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
maximum error 1739 us, estimated error 1 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 4, precision 0.001 us, tolerance 496 ppm,
pps frequency 147.458 ppm, stability 0.535 ppm, jitter 2.156 us,
intervals 67322, jitter exceeded 7483, stability exceeded 0, errors 4.

>> I have a GPS receiver with a PPS output. I understand that a good
>> frequency drift estimation would be good when free running but frankly
>> I don't want my NTP servers to serve time when the GPS signal is not
>> available. I can trust my Meinberg box to do that because it has a
>> TXCO but not my regular NTP servers.
>
>
> The way to do this is to set tinker dispersion on the server, to reflect a
> realistic worst case clock frequency error, and set tos maxdist, on the
> clients, to represent how large an error margin you are prepared to accept.

I will look into this.

>> I was also surprised that Meinberg's NTP server calibration interval
>> never goes above 4 seconds. They must have done what I did.
>>
>> I changed my FreeBSD 8.3 kernel to never go above 4 seconds and the
>> results are in the graphics attached.
>
>
> comp.protocols.time.ntp is not a binaries newsgroup. I believe the mailing
> list imposes similar restrictions.

I noticed that after sending the message.

>> I changed PPS_FAVGDEF in the file /sys/kern/kern_ntptime.c from the
>
>
> No such file in the source distribution, at least not for 4.2.7p333. No
> such symbol in the ntpd sources.

That's because kern_ntptime.c is in the FreeBSD kernel sources and not
in NTP sources.

>> default 8 (256 seconds) to 2 (4 seconds). The frequency is therefore
>> adjusted every 4 seconds instead of 256.
>
>
> I'm going to guess it has something to do with the averaging time for the
> frequency. Generally a longer averaging time will give you a more accurate
> frequency, assuming that phase measurement error noise dominates, which
> should be true below the Allan intercept. Unfortunately, your Allan
> intercept may be exceedingly low and statistically poorly behaved.

Cheers,
Miguel

[Miguel Gonçalves]

On Tue, May 28, 2013 at 8:23 AM, A C <agcarv...@acarver.net> wrote:
>
> Are you allowing kernel discipline in the ntpd configuration? I currently
> have issues with my system going crazy if too many thermal fluctuations
> happen. I have kernel disabled in ntpd.conf (with a "disable kernel"
> directive) but I might consider enabling that if I have a similar
> PPS_FAVGDEF in the NetBSD kernel.

Yes... Kernel discipline is enabled in my reference clock server line
in ntp.conf.

The system goes crazy because it adjusts the frequency every 256
seconds even though you might have low poll intervals (usually 16
seconds for many clocks).

Cheers,
Miguel

[Miguel Gonçalves]

On Tue, May 28, 2013 at 1:46 PM, unruh <un...@invalid.ca> wrote:
> Not really. What would be more helpful would be graphs of the behaviour,
> of the offsets over time, including times when the machines are heavily
> used and times when they are not. (See for example
> www.theory.phsyics.ubc.ca/chrony/chrony.html and past graphs as well)
> Unfortunately the gps attached to my one ntp machine has gone nuts
> (Garmin 18-- both my Garmins failed after about about 2 years. Not a
> very good piece of gear-- but you can look at older graphs from 3 or 4
> years ago to see how the ntp run machine behaved.

Hi Unruh!

I've tried to include the graphs but I forgot that this mailing list
is a gateway for a newsgroup that doesn't accept binaries.

If someone wants to look at them just look here

http://www.flickr.com/photos/miguelbarbosagoncalves/8883017818/in/photostream/
and

http://www.flickr.com/photos/miguelbarbosagoncalves/8882397117/in/photostream/

They are equal machines even though one has a Garmin 18 LVC and the
other one a Sure.

Cheers,
Miguel

[unruh]

I see nothing in those graphs about your system going crazy. It is
disciplining the computer to an offset of less than 5 microseconds. and
with the drift accuracy to about .05PPM. That is perfectly fine and is
what I would expect from a PPS interrupt trigged clock source. Not at
all sure what you are complaining about. There is the oscillation in the
offset with the Garmin. I have seen that as well, and have no idea what
it is about ( some sort of instability in ntpd?) It might be due to the
poll interval ( your offset oscillates with about a 20min period) the
PPS should not have any trouble with the clock filter (all items have
zero delay, so no selection due to delay occurs). Could you pls repeat
what you think the problem is?
>
> Cheers,
> Miguel

[David Woolley]

Miguel Gonçalves wrote:

>
> That's because kern_ntptime.c is in the FreeBSD kernel sources and not
> in NTP sources.
>

This whole issue seems to be a FreeBSD one.

As far as I can tell, on Linux 2.4.33, this value seems to be fixed at 4
seconds and is totally ignored by the time keeping code. It looks like
it is only used to fill the adjtimex result structure.