On 2/25/2012 23:19, David J Taylor wrote:
"A C" <agcarver+...@acarver.net> wrote in message
news:4f49ca89.9090...@acarver.net...
On 2/25/2012 21:55, Ron Frazier (NTP) wrote:
[]
# GPS Lines
server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72
fudge 127.127.20.5 time2 0.3100 refid GPS1
# Internet server lines
# NIST New York
server nist1-ny.ustiming.org minpoll 8 maxpoll 13
# other internet server lines similar
Sincerely,
I know I can do that to the config file but then it takes forever to
synchronize. As I said, the idea was to not give a min/maxpoll so that
ntpd would converge on a clock adjustment quickly (polling once ever
64 seconds) and then, after a couple days, I could throttle back the
polling interval without restarting the server and changing the
configuration file.
"Takes forever" is the problem you should try to solve. With the systems
here, which have a GPS/PPS ref clock, they are synced within a minute of
NTP starting, although it takes longer to get the ultimate accuracy.
What version of ntp are you running, what OS, and what ref clock?
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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
