Date: Thu, 10 May 2007 23:00:58 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: freebsd-stable@FreeBSD.ORG, olli@lurza.secnetix.de Subject: Re: clock problem Message-ID: <20070510.230058.-2001109480.imp@bsdimp.com> In-Reply-To: <200705091640.l49GeW9q055050@lurza.secnetix.de> References: <8EA8AB80-786A-431C-BFFD-6E244D3E25E8@goldmark.org> <200705091640.l49GeW9q055050@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200705091640.l49GeW9q055050@lurza.secnetix.de>
Oliver Fromme <olli@lurza.secnetix.de> writes:
: Martin's Problem with ntpd is not a precision problem.
: His problem is that his ntpd does not synchronize at all.
: Adding more servers certainly won't solve that problem.
There are two causes to not synchronizing at all. One of them is
really crappy hardware. It has been known to happen. One of the
things I do for the commerical ntp servers that my company sells is to
run ntpd on it for a while and monitor the error. If it gets above
150ppm, we RMA the board as defective, as the boards we buy are
usually closer to 30ppm off. This may be the problem if powerd is
running and you are using a source of time that's based on frequency
of the processor. Since powerd is always jerking it around, you will
never measure a stable frequency and you will never converge.
The other time you won't converge is on heavily conjested links. In
this case the jitter to the remote system is so large, and the traffic
patterns so heavy that ntp's assumption that the round trip time is
basically symmetric breaks down. When it is badly asymmetric, you
won't get convergence either.
Well, there is a third cause of noy synchronizing, but he's not
developing a ntpd reference clock driver...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070510.230058.-2001109480.imp>