NTP Cheat Sheet

Hi!

I created a NTP cheat sheet as a short reference for the NTP configuration file
statements and other NTP related stuff. I am pretty sure that I missed something
important and I would appreciate any feedback from you if you can spare a few
minutes.

Here is the link to our NTP download page:
[url]http://www.meinberg.de/english/sw/ntp.htm[/url]

You'll find the cheat sheet near the bottom of this page.

Thanks,
Heiko

Heiko Gerstung wrote:[color=blue]
> Hi!
>
> I created a NTP cheat sheet as a short reference for the NTP
> configuration file statements and other NTP related stuff. I am pretty
> sure that I missed something important and I would appreciate any
> feedback from you if you can spare a few minutes.
>
> Here is the link to our NTP download page:
> [url]http://www.meinberg.de/english/sw/ntp.htm[/url]
>
> You'll find the cheat sheet near the bottom of this page.
>
> Thanks,
> Heiko[/color]

The first thing I noticed was text describing how to change the MINPOLL
and MAXPOLL options. I would add that tinkering with MINPOLL and
MAXPOLL is usually not a good idea. If you need to ask how, you
probably should not be changing them.

Richard B. Gilbert schrieb:[color=blue]
> Heiko Gerstung wrote:[color=green]
>> Hi!
>>
>> I created a NTP cheat sheet as a short reference for the NTP
>> configuration file statements and other NTP related stuff. I am pretty
>> sure that I missed something important and I would appreciate any
>> feedback from you if you can spare a few minutes.
>>
>> Here is the link to our NTP download page:
>> [url]http://www.meinberg.de/english/sw/ntp.htm[/url]
>>
>> You'll find the cheat sheet near the bottom of this page.
>>
>> Thanks,
>> Heiko[/color]
>
> The first thing I noticed was text describing how to change the MINPOLL
> and MAXPOLL options. I would add that tinkering with MINPOLL and
> MAXPOLL is usually not a good idea. If you need to ask how, you
> probably should not be changing them.[/color]

Thanks a lot for your feedback!

In my experience it definitely helps a lot to set the minpoll/maxpoll values to
a lower value when talking to reference clock drivers and your local NTP
servers. On our time server appliances we use minpoll 4 maxpoll 4 for talking to
the integrated refclock (GPS, MSF, DCF77 or IRIG) and this dramatically improves
the reaction times of ntpd when it comes to things like initial synchronization,
reception outtages and so on. Although the parse driver (which we use for all
our refclocks) already has a "fast sync" feature which allows ntpd to accept the
refclock after a few seconds (something like iburst for refclocks), other
refclock drivers can benefit from being able to pass on sync data to ntpd four
times faster than the default.

To me there is no sense in only getting one sample in 64 seconds when your
expensive and highly accurate hardware reference clock offers one very good
sample every second.

But well, this cheat sheet was intended to be used by people with some knowledge
of NTP since there are a lot more advanced configuration options mentioned that
are probably not very interesting for absolute NTP beginners.

Best regards,
Heiko

Heiko,

Be careful when making generalizations about refclocks. Some, including
the Spectracom, Austron, Traconex, TrueTime and others using the median
filter will not workproperly at other than default poll. Same for the
modem and audio drivers.

I don't knkow what version you are using, but the current (development)
version sets the time on the first poll received from a reference clock.
But, !! note carefully !! On one of our servers the first poll recieved
sometimes has a large error (400 ms) that torques the time until brought
right 15 minutes later. Frankly, our servers run for months without
disturbance, so an initial delay to synchronize to a reference clock is
not a big deal.

As a general rule of thumb and confirmed by theory and practice, the
nominal errors increase by a factor of two for each fourfold increase in
poll interval; thus, reducing the poll from 64 to 16 s reduces the
errors by half. This is only true when the time constant is above the
Allan intercept, which is usually in the vicinity of 2000 s. By design,
the time constant is 32 times the poll interval, so 16-s poll is on the
hairy edge.

Dave

Heiko Gerstung wrote:[color=blue]
> Richard B. Gilbert schrieb:
>[color=green]
>> Heiko Gerstung wrote:
>>[color=darkred]
>>> Hi!
>>>
>>> I created a NTP cheat sheet as a short reference for the NTP
>>> configuration file statements and other NTP related stuff. I am
>>> pretty sure that I missed something important and I would appreciate
>>> any feedback from you if you can spare a few minutes.
>>>
>>> Here is the link to our NTP download page:
>>> [url]http://www.meinberg.de/english/sw/ntp.htm[/url]
>>>
>>> You'll find the cheat sheet near the bottom of this page.
>>>
>>> Thanks,
>>> Heiko[/color]
>>
>>
>> The first thing I noticed was text describing how to change the
>> MINPOLL and MAXPOLL options. I would add that tinkering with MINPOLL
>> and MAXPOLL is usually not a good idea. If you need to ask how, you
>> probably should not be changing them.[/color]
>
>
> Thanks a lot for your feedback!
>
> In my experience it definitely helps a lot to set the minpoll/maxpoll
> values to a lower value when talking to reference clock drivers and your
> local NTP servers. On our time server appliances we use minpoll 4
> maxpoll 4 for talking to the integrated refclock (GPS, MSF, DCF77 or
> IRIG) and this dramatically improves the reaction times of ntpd when it
> comes to things like initial synchronization, reception outtages and so
> on. Although the parse driver (which we use for all our refclocks)
> already has a "fast sync" feature which allows ntpd to accept the
> refclock after a few seconds (something like iburst for refclocks),
> other refclock drivers can benefit from being able to pass on sync data
> to ntpd four times faster than the default.
>
> To me there is no sense in only getting one sample in 64 seconds when
> your expensive and highly accurate hardware reference clock offers one
> very good sample every second.
>
> But well, this cheat sheet was intended to be used by people with some
> knowledge of NTP since there are a lot more advanced configuration
> options mentioned that are probably not very interesting for absolute
> NTP beginners.
>
> Best regards,
> Heiko[/color]

> From: "David L. Mills" <mills@udel.edu>[color=blue]
> Date: Wed, 07 May 2008 19:51:20 +0000
> Sender: questions-bounces+oberman=es.net@lists.ntp.org
>
>
> Heiko,
>
> Be careful when making generalizations about refclocks. Some, including
> the Spectracom, Austron, Traconex, TrueTime and others using the median
> filter will not workproperly at other than default poll. Same for the
> modem and audio drivers.[/color]

I assume that this is driver, not device specific.

server 127.127.5.1 prefer minpoll 4 maxpoll 4
fudge 127.127.5.1 refid CDMA
fudge 127.127.5.1 time1 .010
server 127.127.22.1 minpoll 4 maxpoll 4
fudge 127.127.22.1 flag3 1

What about the PPS driver when used with one of these? I use EndRun CDMA
clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and
MAXPOLL of 4. Is that bad advice in such a configuration? If it is
significant, I use FreeBSD on all of my ntp servers.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [email]oberman@es.net[/email] Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

_______________________________________________
questions mailing list
[email]questions@lists.ntp.org[/email]
[url]https://lists.ntp.org/mailman/listinfo/questions[/url]

--- StripMime Report -- processed MIME parts ---
multipart/mixed
multipart/signed
text/plain (text body -- kept)
application/pgp-signature
text/plain (text body -- kept)
---

Keven,

The TrueTime driver that lives here supports all known TrueTime
receivers, including GPS, WWVB and GOES. I strongly suspect one or
another of those receivers would not work if the poll interval was
tinkered. EndRun apparently has cloned most or all that driver and may
have modified it. If they recommend minpoll 4, run that end.

Dave

Kevin Oberman wrote:[color=blue][color=green]
>>From: "David L. Mills" <mills@udel.edu>
>>Date: Wed, 07 May 2008 19:51:20 +0000
>>Sender: questions-bounces+oberman=es.net@lists.ntp.org
>>
>>
>>Heiko,
>>
>>Be careful when making generalizations about refclocks. Some, including
>>the Spectracom, Austron, Traconex, TrueTime and others using the median
>>filter will not workproperly at other than default poll. Same for the
>>modem and audio drivers.[/color]
>
>
> I assume that this is driver, not device specific.
>
> server 127.127.5.1 prefer minpoll 4 maxpoll 4
> fudge 127.127.5.1 refid CDMA
> fudge 127.127.5.1 time1 .010
> server 127.127.22.1 minpoll 4 maxpoll 4
> fudge 127.127.22.1 flag3 1
>
> What about the PPS driver when used with one of these? I use EndRun CDMA
> clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and
> MAXPOLL of 4. Is that bad advice in such a configuration? If it is
> significant, I use FreeBSD on all of my ntp servers.[/color]

Dave,

Thanks for the quick response, but I guess I failed to make one point
clear.

EndRun supplies only the hardware. It is the Ct which as only a serial
interface which is plugged into a standard COM port on the server. They
don't provide any software at all. The clock just provides the time
string every second (with an offset of about 10 ms. and jitter in the
area of 3-5 ms.) and a very accurate PPS which allows us sync within
about three usec. (The clock spec is better than ten usec, but three
seems the norm.)

I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
FreeBSD kernel has PPS support included, so any filtering in the
TrueTime driver should be of little or no impact.

I am assuming than as long as I am using PPS and training the TrueTime
source, a minpoll of 4 is reasonable and I just wanted to make sure that
I am not wrong in doing this.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [email]oberman@es.net[/email] Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
[color=blue]
> From: "David L. Mills" <mills@udel.edu>
> Date: Wed, 07 May 2008 21:38:40 +0000
> Sender: questions-bounces+oberman=es.net@lists.ntp.org
>
>
> Keven,
>
> The TrueTime driver that lives here supports all known TrueTime
> receivers, including GPS, WWVB and GOES. I strongly suspect one or
> another of those receivers would not work if the poll interval was
> tinkered. EndRun apparently has cloned most or all that driver and may
> have modified it. If they recommend minpoll 4, run that end.
>
> Dave
>
> Kevin Oberman wrote:[color=green][color=darkred]
> >>From: "David L. Mills" <mills@udel.edu>
> >>Date: Wed, 07 May 2008 19:51:20 +0000
> >>Sender: questions-bounces+oberman=es.net@lists.ntp.org
> >>
> >>
> >>Heiko,
> >>
> >>Be careful when making generalizations about refclocks. Some, including
> >>the Spectracom, Austron, Traconex, TrueTime and others using the median
> >>filter will not workproperly at other than default poll. Same for the
> >>modem and audio drivers.[/color]
> >
> >
> > I assume that this is driver, not device specific.
> >
> > server 127.127.5.1 prefer minpoll 4 maxpoll 4
> > fudge 127.127.5.1 refid CDMA
> > fudge 127.127.5.1 time1 .010
> > server 127.127.22.1 minpoll 4 maxpoll 4
> > fudge 127.127.22.1 flag3 1
> >
> > What about the PPS driver when used with one of these? I use EndRun CDMA
> > clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and
> > MAXPOLL of 4. Is that bad advice in such a configuration? If it is
> > significant, I use FreeBSD on all of my ntp servers.[/color]
>
> _______________________________________________
> questions mailing list
> [email]questions@lists.ntp.org[/email]
> [url]https://lists.ntp.org/mailman/listinfo/questions[/url]
>[/color]

_______________________________________________
questions mailing list
[email]questions@lists.ntp.org[/email]
[url]https://lists.ntp.org/mailman/listinfo/questions[/url]

--- StripMime Report -- processed MIME parts ---
multipart/mixed
multipart/signed
text/plain (text body -- kept)
application/pgp-signature
text/plain (text body -- kept)
---

Kevin,

Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
works for you use it. That's a pretty grotty driver with all kinds of
bandaids to deal with long forgotten radios; I wonder why EndRun chose
that driver...

Dave

Kevin Oberman wrote:[color=blue]
> Dave,
>
> Thanks for the quick response, but I guess I failed to make one point
> clear.
>
> EndRun supplies only the hardware. It is the Ct which as only a serial
> interface which is plugged into a standard COM port on the server. They
> don't provide any software at all. The clock just provides the time
> string every second (with an offset of about 10 ms. and jitter in the
> area of 3-5 ms.) and a very accurate PPS which allows us sync within
> about three usec. (The clock spec is better than ten usec, but three
> seems the norm.)
>
> I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
> FreeBSD kernel has PPS support included, so any filtering in the
> TrueTime driver should be of little or no impact.
>
> I am assuming than as long as I am using PPS and training the TrueTime
> source, a minpoll of 4 is reasonable and I just wanted to make sure that
> I am not wrong in doing this.[/color]

Heiko Gerstung wrote:[color=blue]
> local NTP servers. On our time server appliances we use minpoll 4
> maxpoll 4 for talking to the integrated refclock (GPS, MSF, DCF77 or
> IRIG) and this dramatically improves the reaction times of ntpd when it[/color]

Dave Mills, you again need to note the "market" perception that ntpd has
poor transient responses.
[color=blue]
> comes to things like initial synchronization, reception outtages and so
> on. Although the parse driver (which we use for all our refclocks)[/color]

As I understand it, maxpoll has rather limited impact. The most it may
do is speed up the detection of a phase hit. As I understand it setting
a low maxpoll simply causes oversampling of the data without actually
limiting the minimum filter bandwidth. I suspect that is why the
subsequent discussion only mentions minpoll.
[color=blue]
>
> To me there is no sense in only getting one sample in 64 seconds when
> your expensive and highly accurate hardware reference clock offers one
> very good sample every second.[/color]

Most highly accurate reference clocks do not produce high accuracy on
their NMEA output, but rather on their PPS one. ntpd only requires the
NMEA input to be good to a second, in that case.[color=blue]
>[/color]

David Woolley schrieb:[color=blue]
> Heiko Gerstung wrote:[color=green]
>> local NTP servers. On our time server appliances we use minpoll 4
>> maxpoll 4 for talking to the integrated refclock (GPS, MSF, DCF77 or
>> IRIG) and this dramatically improves the reaction times of ntpd when it[/color]
>
> Dave Mills, you again need to note the "market" perception that ntpd has
> poor transient responses.
>[color=green]
>> comes to things like initial synchronization, reception outtages and
>> so on. Although the parse driver (which we use for all our refclocks)[/color]
>
> As I understand it, maxpoll has rather limited impact. The most it may
> do is speed up the detection of a phase hit. As I understand it setting
> a low maxpoll simply causes oversampling of the data without actually
> limiting the minimum filter bandwidth. I suspect that is why the
> subsequent discussion only mentions minpoll.[/color]

For me maxpoll is an important parameter as well because ntpd switches to larger
polling intervals pretty fast and for a lot of our customers it is important
that ntpd recognizes as fast as possible if a GPS signal is lost or the GPS
receiver/IRIG time code reader/AM radio looses sync for some other reason. They
want the unit to switch as soon as possible to a fallback source which will take
significantly longer with a polling interval of 64s when compared to 16s ... the
same applies when the refclock recovers after becoming unsynchronized.
[color=blue][color=green]
>> To me there is no sense in only getting one sample in 64 seconds when
>> your expensive and highly accurate hardware reference clock offers one
>> very good sample every second.[/color][/color]
[color=blue]
> Most highly accurate reference clocks do not produce high accuracy on
> their NMEA output, but rather on their PPS one. ntpd only requires the
> NMEA input to be good to a second, in that case.[/color]

Yes, but in our case the parse driver utilizes the PPSAPI under Linux (as does
the NMEA driver) which means that your refclock driver gets a measurement (based
on the PPS) each second.

Regards,
Heiko

Dave,

When introducing our CDMA technology, EndRun thought it wise to make the
initial product emulate existing hardware that had already been
interfaced to unix machines via the serial port and "gadget boxes." The
CDMA engine which is inside both the Ct and your Cntp emulates both the
Truetime and Spectracom time strings, with 1PPS on DCD. In addition, it
emulates the Trimble Palisade event capture mode on the CTS input, with
30 ns resolution. One benefit to this driver is high resolution
capability on the Windows platform, another is not needing to mess with
kernels that don't natively support high-resolution 1PPS timetagging.

Users of the Ct can choose the emulation mode they like and use the
standard drivers in the stock ntp distribution. However, all of our ntp
servers operate the CDMA or GPS engine in the CTS event capture mode
with a heavily customized refclock driver.

While developing our first generation ntp servers (your Cntp is one of
these) using off the shelf X86 embedded single board computers running
linux, we found that longer poll intervals definitely exposed the
instabilities of the uncompensated crystals used on these boards. We
found that with high measurement precision and holding the poll interval
at 16 seconds, one microsecond level offset control could be maintained
reliably, and have never experienced any loop damping issues.

Our current products contain our own purpose-built X86 core with clocks
that are hardware phase locked to the main system disciplined
oscillator, which could be TCXO, OCXO or Rubidium. In these units, a
shorter polling interval is really only an issue at startup for more
rapid ntp lock because the kernel clock is rock solid between polls.

Bruce Penrod

David L. Mills wrote:[color=blue]
> Kevin,
>
> Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
> works for you use it. That's a pretty grotty driver with all kinds of
> bandaids to deal with long forgotten radios; I wonder why EndRun chose
> that driver...
>
> Dave
>
> Kevin Oberman wrote:[color=green]
>> Dave,
>>
>> Thanks for the quick response, but I guess I failed to make one point
>> clear.
>> EndRun supplies only the hardware. It is the Ct which as only a serial
>> interface which is plugged into a standard COM port on the server. They
>> don't provide any software at all. The clock just provides the time
>> string every second (with an offset of about 10 ms. and jitter in the
>> area of 3-5 ms.) and a very accurate PPS which allows us sync within
>> about three usec. (The clock spec is better than ten usec, but three
>> seems the norm.)
>>
>> I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
>> FreeBSD kernel has PPS support included, so any filtering in the
>> TrueTime driver should be of little or no impact.
>>
>> I am assuming than as long as I am using PPS and training the TrueTime
>> source, a minpoll of 4 is reasonable and I just wanted to make sure that
>> I am not wrong in doing this.[/color][/color]

Dave,

Not really strange. The Ct is an old design from EndRun that is very
small and allows the server to run additional software. The latter is
the reason we continue to deploy the Ct. (Just bought 10 more and are
about to order another 10.)

The systems to which these clocks are connected need to also run OWAMP
<http://e2epi.internet2.edu/owamp/>, a one-way ping tool. It is only as
accurate as the times on the client and server, so we need single digit
usec. sync between the systems which are scattered all over the
country.

It's quite nice to have a tool that tells you that a circuit has moved
from working to protect because you can see the propagation time
increase by 40 usec. and we can do exactly that. It is a key part of our
high performance network monitoring system.

That is why we have found the Ct to be the ideal unit for our
purposes. It can emulate several different clocks including TrueTime and
Trimble Palisade, but, in our testing, we concluded that Either TrueTime
or Spectracom emulation with PPS kernel support provided the most
accurate and stable time.

In any case, thank you for the information. While I've been working with
NTP since at least V2 days, I won't claim to really understand all of
the gory details and some of the non-intuitive behaviors.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [email]oberman@es.net[/email] Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
[color=blue]
> From: "David L. Mills" <mills@udel.edu>
> Date: Thu, 08 May 2008 03:21:49 +0000
> Sender: questions-bounces+oberman=es.net@lists.ntp.org
>
>
> Kevin,
>
> Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
> works for you use it. That's a pretty grotty driver with all kinds of
> bandaids to deal with long forgotten radios; I wonder why EndRun chose
> that driver...
>
> Dave
>
> Kevin Oberman wrote:[color=green]
> > Dave,
> >
> > Thanks for the quick response, but I guess I failed to make one point
> > clear.
> >
> > EndRun supplies only the hardware. It is the Ct which as only a serial
> > interface which is plugged into a standard COM port on the server. They
> > don't provide any software at all. The clock just provides the time
> > string every second (with an offset of about 10 ms. and jitter in the
> > area of 3-5 ms.) and a very accurate PPS which allows us sync within
> > about three usec. (The clock spec is better than ten usec, but three
> > seems the norm.)
> >
> > I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
> > FreeBSD kernel has PPS support included, so any filtering in the
> > TrueTime driver should be of little or no impact.
> >
> > I am assuming than as long as I am using PPS and training the TrueTime
> > source, a minpoll of 4 is reasonable and I just wanted to make sure that
> > I am not wrong in doing this.[/color]
>
> _______________________________________________
> questions mailing list
> [email]questions@lists.ntp.org[/email]
> [url]https://lists.ntp.org/mailman/listinfo/questions[/url]
>[/color]

_______________________________________________
questions mailing list
[email]questions@lists.ntp.org[/email]
[url]https://lists.ntp.org/mailman/listinfo/questions[/url]

--- StripMime Report -- processed MIME parts ---
multipart/mixed
multipart/signed
text/plain (text body -- kept)
application/pgp-signature
text/plain (text body -- kept)
---

Heiko Gerstung wrote:[color=blue]
> For me maxpoll is an important parameter as well because ntpd switches
> to larger polling intervals pretty fast and for a lot of our customers
> it is important that ntpd recognizes as fast as possible if a GPS signal
> is lost or the GPS receiver/IRIG time code reader/AM radio looses sync[/color]

But ntpd should only switch to a long poll interval if it believes that
it will not accumulate a significant error if it drifts for many times
the poll interval, so, if the poll interval is long the time available
before you need to switch to an alternative source is also long.

I think what you are actually saying is that you believe there is a bug
in ntpd that causes it to increase the loop time constant prematurely.

The other possibility is that you are are saying that your reference
clocks will give out wrong times for a significant period before they
declare themselves down, and you want the accumuated error wiped out as
soon as possible after the clock discovers its is giving bad times.
Even then, a long loop time constant will require bad input for a long
time to cause real problems.

However, it looks to me as though the code only ever uses the minpoll
value for reference clocks unless the clock driver itself actually
overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
sure I've not missed something, though, and I don't have a system with a
reference clock to check.

[color=blue]
> for some other reason. They want the unit to switch as soon as possible
> to a fallback source which will take significantly longer with a polling
> interval of 64s when compared to 16s ... the same applies when the
> refclock recovers after becoming unsynchronized.[/color]

There is a better case for this, always assuming that maxpoll is
relevant for reference clocks.

David Woolley schrieb:[color=blue]
> Heiko Gerstung wrote:[color=green]
>> For me maxpoll is an important parameter as well because ntpd switches
>> to larger polling intervals pretty fast and for a lot of our customers
>> it is important that ntpd recognizes as fast as possible if a GPS
>> signal is lost or the GPS receiver/IRIG time code reader/AM radio
>> looses sync[/color]
>
> But ntpd should only switch to a long poll interval if it believes that
> it will not accumulate a significant error if it drifts for many times
> the poll interval, so, if the poll interval is long the time available
> before you need to switch to an alternative source is also long.
>
> I think what you are actually saying is that you believe there is a bug
> in ntpd that causes it to increase the loop time constant prematurely.
>
> The other possibility is that you are are saying that your reference
> clocks will give out wrong times for a significant period before they
> declare themselves down, and you want the accumuated error wiped out as
> soon as possible after the clock discovers its is giving bad times. Even
> then, a long loop time constant will require bad input for a long time
> to cause real problems.[/color]

No, I apologize if I did not make this clear. I said that our customers want
ntpd to show that something is wrong with the internal time source, probably for
management reasons. Additionally they often deploy more than one refclock and if
one of them looses sync, they want the second unit to take over.

I strongly assume that ntpd is correctly increasing the polling interval.

Of course our refclocks will not give out wrong time for a significant period
:-) ...
[color=blue]
> However, it looks to me as though the code only ever uses the minpoll
> value for reference clocks unless the clock driver itself actually
> overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
> sure I've not missed something, though, and I don't have a system with a
> reference clock to check.[/color]

I have a system with a refclock and it honours the minpoll / maxpoll settings
just like other association types do.
[color=blue][color=green]
>> for some other reason. They want the unit to switch as soon as
>> possible to a fallback source which will take significantly longer
>> with a polling interval of 64s when compared to 16s ... the same
>> applies when the refclock recovers after becoming unsynchronized.[/color]
>
> There is a better case for this, always assuming that maxpoll is
> relevant for reference clocks.[/color]

What do you mean with "better case"?

Best Regards,
Heiko

Heiko Gerstung <heiko.gerstung@meinberg.de> writes:
[color=blue]
>David Woolley schrieb:[color=green]
>> Heiko Gerstung wrote:[color=darkred]
>>> For me maxpoll is an important parameter as well because ntpd switches
>>> to larger polling intervals pretty fast and for a lot of our customers
>>> it is important that ntpd recognizes as fast as possible if a GPS
>>> signal is lost or the GPS receiver/IRIG time code reader/AM radio
>>> looses sync[/color]
>>
>> But ntpd should only switch to a long poll interval if it believes that
>> it will not accumulate a significant error if it drifts for many times
>> the poll interval, so, if the poll interval is long the time available
>> before you need to switch to an alternative source is also long.
>>
>> I think what you are actually saying is that you believe there is a bug
>> in ntpd that causes it to increase the loop time constant prematurely.
>>
>> The other possibility is that you are are saying that your reference
>> clocks will give out wrong times for a significant period before they
>> declare themselves down, and you want the accumuated error wiped out as
>> soon as possible after the clock discovers its is giving bad times. Even
>> then, a long loop time constant will require bad input for a long time
>> to cause real problems.[/color][/color]
[color=blue]
>No, I apologize if I did not make this clear. I said that our customers want
>ntpd to show that something is wrong with the internal time source, probably for
>management reasons. Additionally they often deploy more than one refclock and if
>one of them looses sync, they want the second unit to take over.[/color]
[color=blue]
>I strongly assume that ntpd is correctly increasing the polling interval.[/color]
[color=blue]
>Of course our refclocks will not give out wrong time for a significant period
>:-) ...[/color]

Why would you want the poll interval to increase on a refclock? It is not
as though you are going to swamp it even if you poll it every 16 sec.


[color=blue][color=green]
>> However, it looks to me as though the code only ever uses the minpoll
>> value for reference clocks unless the clock driver itself actually
>> overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
>> sure I've not missed something, though, and I don't have a system with a
>> reference clock to check.[/color][/color]
[color=blue]
>I have a system with a refclock and it honours the minpoll / maxpoll settings
>just like other association types do.[/color]
[color=blue][color=green][color=darkred]
>>> for some other reason. They want the unit to switch as soon as
>>> possible to a fallback source which will take significantly longer
>>> with a polling interval of 64s when compared to 16s ... the same
>>> applies when the refclock recovers after becoming unsynchronized.[/color]
>>
>> There is a better case for this, always assuming that maxpoll is
>> relevant for reference clocks.[/color][/color]
[color=blue]
>What do you mean with "better case"?[/color]
[color=blue]
>Best Regards,
> Heiko[/color]

David,

There is need to dispell urban legends here. First, the only reference
clock driver that uses anything other than minpoll is the ACTS driver.
All others do not increase the poll interval under any circumstances.
Second, there is no failover at all. The design is that more than one
reference clock driver is happily supported at the same time. Their
contributions are continuously evaluated and mitigated, so there is no
delay in using one or the other or both. If the intended behavior is to
"fail over" in the usual sense of those words, you should be using
something other than NTP>

Dave

David Woolley wrote:[color=blue]
> Heiko Gerstung wrote:
>[color=green]
>> For me maxpoll is an important parameter as well because ntpd switches
>> to larger polling intervals pretty fast and for a lot of our customers
>> it is important that ntpd recognizes as fast as possible if a GPS
>> signal is lost or the GPS receiver/IRIG time code reader/AM radio
>> looses sync[/color]
>
>
> But ntpd should only switch to a long poll interval if it believes that
> it will not accumulate a significant error if it drifts for many times
> the poll interval, so, if the poll interval is long the time available
> before you need to switch to an alternative source is also long.
>
> I think what you are actually saying is that you believe there is a bug
> in ntpd that causes it to increase the loop time constant prematurely.
>
> The other possibility is that you are are saying that your reference
> clocks will give out wrong times for a significant period before they
> declare themselves down, and you want the accumuated error wiped out as
> soon as possible after the clock discovers its is giving bad times. Even
> then, a long loop time constant will require bad input for a long time
> to cause real problems.
>
> However, it looks to me as though the code only ever uses the minpoll
> value for reference clocks unless the clock driver itself actually
> overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
> sure I've not missed something, though, and I don't have a system with a
> reference clock to check.
>
>[color=green]
>> for some other reason. They want the unit to switch as soon as
>> possible to a fallback source which will take significantly longer
>> with a polling interval of 64s when compared to 16s ... the same
>> applies when the refclock recovers after becoming unsynchronized.[/color]
>
>
> There is a better case for this, always assuming that maxpoll is
> relevant for reference clocks.
>[/color]

David L. Mills wrote:[color=blue]
>
> There is need to dispell urban legends here. First, the only reference
> clock driver that uses anything other than minpoll is the ACTS driver.[/color]

You introduced the possibility that there were exceptions, yourself,
earlier in the thread; I was just caveating what I wrote to cater for that.
[color=blue]
> All others do not increase the poll interval under any circumstances.[/color]

Yes. That's how I read the code; however Heiko appears to have
empirical evidence to the contrary. (One thought I had is that there
seems to be more than one state variable involved and maybe ntpq peers
doesn't show the actual poll interval)
[color=blue]
> Second, there is no failover at all. The design is that more than one[/color]

I suspect failover is concept that customers and salesmen like. I do
try to stress that ntpd averages multiple sources (and the weighting
isn't tied to the current system peer). One other aspect of that
particular myth is the concept of clock hopping. I think clock hopping
can only happen if you have enough clocks that the set of retained
clocks changes. I'm sure a lot of people believe that ntpd only uses
data from the current "system peer".

One caveat, as I understand it, if they used a prefer keyword, ntpd
would failover from that server to an average of all the others.
[color=blue]
> reference clock driver is happily supported at the same time. Their
> contributions are continuously evaluated and mitigated, so there is no
> delay in using one or the other or both. If the intended behavior is to
> "fail over" in the usual sense of those words, you should be using
> something other than NTP>[/color]

I think you meant Heiko should be.

David,

The flag FLAG_FIXPOLL is defined for all reference clock driverss except
ACTS. With this flag defined, the poll interval is fixed at minpoll. See
ntp_refclock.c and ntp_proto.c.

Having thought about it, there actually are two scenarios involving
failover, one with the local clock driver, the other with the modem
driver. These driver are disabled unless all other sources are lost or
not configured. For the local clock driver, this was done to avoid nasty
cases when the local clock driver escaped to the Internet at large,
which has in fact happened on occasion.

Dave

David Woolley wrote:[color=blue]
> David L. Mills wrote:
>[color=green]
>>
>> There is need to dispell urban legends here. First, the only reference
>> clock driver that uses anything other than minpoll is the ACTS driver.[/color]
>
>
> You introduced the possibility that there were exceptions, yourself,
> earlier in the thread; I was just caveating what I wrote to cater for that.
>[color=green]
>> All others do not increase the poll interval under any circumstances.[/color]
>
>
> Yes. That's how I read the code; however Heiko appears to have
> empirical evidence to the contrary. (One thought I had is that there
> seems to be more than one state variable involved and maybe ntpq peers
> doesn't show the actual poll interval)
>[color=green]
>> Second, there is no failover at all. The design is that more than one[/color]
>
>
> I suspect failover is concept that customers and salesmen like. I do
> try to stress that ntpd averages multiple sources (and the weighting
> isn't tied to the current system peer). One other aspect of that
> particular myth is the concept of clock hopping. I think clock hopping
> can only happen if you have enough clocks that the set of retained
> clocks changes. I'm sure a lot of people believe that ntpd only uses
> data from the current "system peer".
>
> One caveat, as I understand it, if they used a prefer keyword, ntpd
> would failover from that server to an average of all the others.
>[color=green]
>> reference clock driver is happily supported at the same time. Their
>> contributions are continuously evaluated and mitigated, so there is no
>> delay in using one or the other or both. If the intended behavior is
>> to "fail over" in the usual sense of those words, you should be using
>> something other than NTP>[/color]
>
>
> I think you meant Heiko should be.[/color]

David L. Mills schrieb:[color=blue]
> David,
>
> The flag FLAG_FIXPOLL is defined for all reference clock driverss except
> ACTS. With this flag defined, the poll interval is fixed at minpoll. See
> ntp_refclock.c and ntp_proto.c.[/color]

OK, that explains it :-) We use "minpoll 4 maxpoll 4" because we want the
reference clock to be polled every 16s ... Looks like "minpoll" directly affects
the maximum polling interval for refclocks (because there is no "minpoll" or
"maxpoll", just a "fixpoll" functionality).
[color=blue]
> Having thought about it, there actually are two scenarios involving
> failover, one with the local clock driver, the other with the modem
> driver. These driver are disabled unless all other sources are lost or
> not configured. For the local clock driver, this was done to avoid nasty
> cases when the local clock driver escaped to the Internet at large,
> which has in fact happened on occasion.[/color]

The "Failover" mode is something engineers in most industry segments know and
use for all kinds of mission critical stuff, it is often hard or impossible to
convince them that for time synchronization a majority approach is the best
solution. For some strange reason it sounds a little bit suspicious when a time
server manufacturer tells you that "you should use four instead of two time
servers to be protected against ..." :-)

Heiko
[color=blue]
>
> Dave
>
> David Woolley wrote:[color=green]
>> David L. Mills wrote:
>>[color=darkred]
>>>
>>> There is need to dispell urban legends here. First, the only
>>> reference clock driver that uses anything other than minpoll is the
>>> ACTS driver.[/color]
>>
>>
>> You introduced the possibility that there were exceptions, yourself,
>> earlier in the thread; I was just caveating what I wrote to cater for
>> that.
>>[color=darkred]
>>> All others do not increase the poll interval under any circumstances.[/color]
>>
>>
>> Yes. That's how I read the code; however Heiko appears to have
>> empirical evidence to the contrary. (One thought I had is that there
>> seems to be more than one state variable involved and maybe ntpq peers
>> doesn't show the actual poll interval)
>>[color=darkred]
>>> Second, there is no failover at all. The design is that more than one[/color]
>>
>>
>> I suspect failover is concept that customers and salesmen like. I do
>> try to stress that ntpd averages multiple sources (and the weighting
>> isn't tied to the current system peer). One other aspect of that
>> particular myth is the concept of clock hopping. I think clock
>> hopping can only happen if you have enough clocks that the set of
>> retained clocks changes. I'm sure a lot of people believe that ntpd
>> only uses data from the current "system peer".
>>
>> One caveat, as I understand it, if they used a prefer keyword, ntpd
>> would failover from that server to an average of all the others.
>>[color=darkred]
>>> reference clock driver is happily supported at the same time. Their
>>> contributions are continuously evaluated and mitigated, so there is
>>> no delay in using one or the other or both. If the intended behavior
>>> is to "fail over" in the usual sense of those words, you should be
>>> using something other than NTP>[/color]
>>
>>
>> I think you meant Heiko should be.[/color][/color]