[ntp:questions] Change poll interval at runtime?

A C agcarver+ntp at acarver.net
Sun Feb 26 19:30:43 UTC 2012


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.


More information about the questions mailing list