[ntp:questions] NTPd instability and openntpd

Harlan Stenn stenn at ntp.org
Sat Sep 15 00:41:31 UTC 2007


>>> In article <1189810830.509730.286200 at d55g2000hsg.googlegroups.com>, Mij <mij at bitchx.it> writes:

mij> I submitted to pool.ntp.org with a stratum 2 NTPd server. The useful
mij> system scoring however shows me significant discontinuity in the
mij> service:

mij> http://www.pool.ntp.org/scores/81.208.58.150

I recommend plotting your own statistics.  Have you seen:

 http://support.ntp.org/Support/MonitoringAndControllingNTP

Has it been clearly determined that it's ntpd as opposed to a network
problem?

mij> The host is a dual processor FreeBSD host with low load, today counting
mij> 107 days of uptime. The connectivity is a 11Mbps fiber optic, that
mij> proven pretty reliable in the last five years.  So I did not believe
mij> those stats first and put a polling script on another server 150 km
mij> away from this one. Unfortunately or not, it confirmed the downtimes.

What is the network path between these 2 servers?

For example, I have a customer who has decent bandwidth from his office to
his ISP, and decent bandwidth from his house to that ISP.  His house is not
all that far from his office.  Network traffic between his house and his
office (different ISPs) is often slow.

mij> So NTPd seems the only point of guilt. I re-compiled with debugging
mij> enabled to trace the problem. I could be unable to read its debugging
mij> dumps, but its L1 and L2 debug levels proven useless to me. For
mij> example, none did show client request coming in, nor served nor
mij> rejected. L1 is quite a lot verbose and L2 is extremely verbose, so
mij> further levels would be simply unreadable to me.

I'm not sure that this would help all that much at this point.

mij> NTPd is not under explicit ulimit. Confs are nearly freebsd's defaults
mij> (5 servers are used and some statistics are enabled).

mij> In favour of sparing some time I tried possible alternatives. I see
mij> OpenNTPd favourably, as openbsd's software typically works simply and
mij> well. But I see some (old, not up to date) criticism on its precision
mij> and stuffing an imprecise server into the pool would be quite
mij> unethical.

mij> So a twofold request: 1) any suggestion for a better mean to trace down
mij> the instability problem of NTPd ?

I'd recommend locally plotting stats on all your local machines, and perhaps
including some stats on your remote servers.  If you could also plot the
stats from a remote machine of your local servers and some other remote
machine that would also give you a useful perspective.

mij>  2) any comment on the current
mij> quality of openntpd, notably if it is suitable to be run in
mij> pool.ntp.org

I do not speak for the pool.

The last I saw, openntpd was an SNTP implementation.  The RFCs require that
the only way an SNTP server may offer time to other (S)NTP clients is if
there is a directly-attached refclock.  If you want to be in the pool, the
RFCs would require you to have a refclock to drive your SNTP server in order
for it to serve time.

H




More information about the questions mailing list