[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
martin.burnicki at meinberg.de
Mon Feb 9 12:33:15 UTC 2009
Harlan Stenn wrote:
>>>> In article <7q7r56-9tb.ln1 at gateway.py.meinberg.de>, Martin Burnicki
>>>> <martin.burnicki at meinberg.de> writes:
> Martin> *only* sends via an unprivileged port if either -q (query only),
> Martin> (unpriv. port), or -d (debug) is given on the command line.
> Harlan> First, given that ntpdate is about to be deprecated in favor of
> the Harlan> new SNTP Client, ...
> Martin> The topic of this thread is ntpdate vs. ntpd, and I just wanted to
> Martin> clarify some statements about ntpdate which are simply wrong.
> Yes, and since ntpdate is being deprecated with the replacement being
> various combinations of ntpd and sntp I figured we might as well be sure
> any desired changes could be accomodated "in the future":
Please see my comments about porting sntp in my reply to Danny ...
Unless some cleanup is going to happen in the way common code is shared
across the whole ntp/sntp project the sntp subproject will suffer in a few
years from the same problems as ntpdate is suffering now.
> Because ntpd also gets restarted, and there is a strong belief that -g is
> bad for a restart and restarts will happen more often than boots.
Huh? I'm afraid I don't understand what you mean here.
If ntpd is started and the initial offset is large I would expect ntpd to
correct it (initially, as said).
If the initial time offset is small then there should be no difference
whether -g has been given, or not.
Or am I missing something?
> Martin> Anyway, ntpdate is still very good to debug NTP problems.
> And sntp should be able to take over that role.
Yep, once it has been ported to Windows ... ;-)
> Martin> Now gsoc-sntp is there, and I don't see how this could be built
> Martin> e.g. under Windows. What I see is that a number of functions which
> Martin> are available in ntpd and can be used both under Unix and windows
> Martin> have again been duplicated/rewritten in gsoc-sntp. So there is one
> Martin> more code base which needs to be ported and maintained. Great.
> First, the intent is that gsoc-sntp will build under Windows.
> Second, there wasn't time during GSoC to revamp the code tree so a single
> common codebase was used. This is something we intend to do, but it will
> not happen before 4.2.6 comes out.
> There was also a fair amount of discussion about whether or not the sntp
> codebase should be completely separate from the ntpd codebase.
> My decision was to have them share code whenever possible, and unless I am
> convinced the other can of worms is tastier, this is what we'll be doing.
I would also appreciate if more code would be shared, especiale with regard
to compatibility issues. As already written in my reply to Danny, different
API calls for Windows/Unix, WSAGetLastError() vs. errno to retrieve an
error code, etc. come in mind.
Specially the latter makes it impossible just to use something like perror()
in code which should be shared under Windows, Unix, and maybe other OSs.
This has partly been resolved in the NTP code, but there are still places
which need to be cleaned up. And the whole thing will have to be duplicated
for sntp unless the code is shared in a better way ...
> Martin> BTW, the same basic problem is with the ISC libraries, which also
> Martin> seem to have been copied e.g. from ISC's bind. Nowadays there a
> Martin> different versions of the same source code modules both in libisc/
> Martin> and ports/winnt/libisc, e.g. interfaceiter.c, isc_strerror.c, and
> Martin> net.c.
> This was a mistake IMO, and there should have been a single codebase. I
> believe the reason for it is that in the stock ISC libisc/, there are
> subdirs for unix/ and win32/ and when Danny(?) did the initial import of
> libisc the main codebase was flattened a bit and it contains the Unix
> code, and the ports/winnt/ subtree contains the win32/ code.
> This should get better when ISC releases libisc as a tearoff/standalone
> My intent is to import libisc as a single unit, and this will affect the
> build scripts for Windows.
The build scripts needed to be modified only once, but the lng term
maintenance would clearly benefit if those libs are only in a single unit.
More information about the questions