[ntp:questions] Change poll interval at runtime?

Ron Frazier (NTP) timekeepingntplist at c3energy.com
Sun Feb 26 22:04:13 UTC 2012

On 2/26/2012 2:30 PM, A C wrote:
> On 2/26/2012 10:20, David J Taylor wrote:
>> "A C" <agcarver+ntp at acarver.net> wrote in message
>> news:4F4A6E79.3010707 at acarver.net...
>> []
>>> It's the latest dev version on NetBSD using five network servers plus
>>> the SHM refclock plus the ATOM refclock. The SHM is not very stable
>>> with its offset so I don't use it right now which leaves me ATOM plus
>>> network (one of the network servers is marked prefer). (Don't ask
>>> about using NMEA with PPS enabled, it doesn't work due to the serial
>>> drivers on NetBSD/sparc so PPS has to be separate via a second serial
>>> port).
>>> If I set minpoll to 8 or 9 to be nice to the network servers, it takes
>>> six or eight polling periods before ATOM turns on and becomes the
>>> system peer. If I leave out minpoll, ATOM clamps the polling period to
>>> 64 seconds. It still takes six to eight polling periods to activate
>>> ATOM but 8 * 64 is much less than 8 * 256 or 8 * 512.
>> Thanks for that summary, there are so many systems being discussed that
>> it's easy to lose touch!
>> Leaving aside the question of when the ATOM driver becomes selected,
>> isn't the time accurate enough for your purposes simply by using the
>> five networks servers within a minute or two? I take it that you have
>> "iburst" against all the servers, and that you have one of them marked
>> "prefer"? Can you accept a reduced accuracy until the ATOM kicks in?
> I've done it before so it's entirely possible to let it go for the 
> total cycle time until ATOM is selected, it just means that the system 
> then takes a while to slew into position after it has been on the 
> Internet servers for a while.  I was just hoping to have the best of 
> both, faster convergence and then a kinder polling period afterwards.
>> In the discussions I had with Dave Mills here some time back, I recall
>> that it was a requirement that is the ref clock was at 16s intervals,
>> the Internet servers shouldn't be at 1024s, although that does seem to
>> work correctly here. I have at the back of my mind a feeling that it's
>> tied in with the NMEA not working, i.e. the ATOM driver is somehow
>> working on its own (as an edge of second reference) without a "time of
>> day" source being polled at a similar interval.
>> Anyway, all I can suggest is trying FreeBSD and seeing whether its
>> serial drivers will work for you. I don't feel I can help further.
> FreeBSD's serial drivers are also very broken (in fact, even more 
> broken than NetBSD because FreeBSD can't even see the DCD line).
> I'll just experiment with the keys and ntpq commands that Dave Hart 
> suggested.  That will probably get me what I'm looking for though I 
> may have to stagger the drops and re-adds if it is truly a drop and 
> re-add rather than just updating the parameters.

I just had a thought that I wanted to share.  Now, I know just enough 
about Linux to be really dangerous, and nothing about any form of BSD.  
So, people who do know about such things may laugh at this idea.  But, 
what if you could do this:

Write your own special script to start up NTPD.  Have two versions of 
ntp.conf, say, ntp.conf-fast and ntp.conf-slow.  When the script starts, 
first copy ntp.conf-fast over to /etc/ntp.conf (or wherever it lives).  
Then, the script starts NTPD.  Then the script goes to sleep.  During 
this time, NTPD will be running with a version of ntp.conf which sets 
polling intervals very fast to get quick convergence.  After NTPD has 
been running, and the script has been sleeping for, say, 10 minutes, 
let's suppose that the PC clock is very close to the GPS time or a 
preferred internet server.  (I realize the term "very close" can be 
interpreted different ways.)  Say it's within 10 ms.  After 10 minutes, 
the script wakes up again.  It shuts down NTPD.  Then, it copies 
ntp.conf-slow over to /etc/ntp.conf.  Then, it restarts NTPD.  Now the 
script terminates, but NPTD keeps running.  Now, however, NTPD is 
running with an ntp.conf file that has longer polling intervals that you 
want after the system is stable.  When NTPD is restarted, it SHOULD 
maintain the close alignment of the PC clock to the preferred source, I 
think.  It should pick up running about where it left off, and then fine 
tune the synchronization over the next few hours, perhaps.  That way, 
you could have your cake and eat it too.  Short polling intervals at 
first, then longer ones.

If, HOWEVER, you encounter the phenomenon (bug?) I've experienced in 
Linux, you clock will jump to a large offset when NTPD starts up, and 
that will foil the plan.

My approach of polling the GPS at very short minimum intervals and the 
internet servers at longer minimum intervals seems to be working OK.  As 
long as my GPS time is normally not too far out from what the internet 
servers are reporting, it should still fail over to the internet if the 
GPS becomes unreliable.




(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

More information about the questions mailing list