[ previous ] [ next ] [ threads ]
 From:  Bart Smit <bit at signature dot nl>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  [m0n0wall] Re: time client/server proposal - comments please
 Date:  Tue, 17 Jun 2003 20:17:09 +0200 (CEST)
Oops, forgot to CC the list.

---------- Forwarded message ----------
Date: Tue, 17 Jun 2003 19:55:41 +0200 (CEST)
From: Bart Smit <bit at signature dot nl>
To: Michael Mee <mm2001 at pobox dot com>
Subject: Re: [m0n0wall] Re: time client/server proposal - comments please

On Tue, 17 Jun 2003, Michael Mee wrote:

> Wow, lots of good feedback - thanks all!

Whoa! Missed most of this. Didn't read too much mail for 2 days and there
you are...

Has the choice for msntp already been made? If so, why msntp in favor of
'"regular" ntp? If at all possible I'd urge you to reconsider. ntp is
capable of a few tricks (such as supporting reference clocks) that I don't
see in msntp. Also, according to the msntp readme file, even the most
common usage scenario for m0n0wall doesn't really fit msntp, which is
intended to answer the following requirements:

<quote readme of 1.6>

MSNTP is intended to be a straightforward SNTP daemon/utility that is easy
to build on any reasonable Unix platform (and most near-Unix ones),
whether or not it has ever been ported to them before.  It is intended to
answer the following requirements, either by challenge and response or the
less reliable broadcast method:

    A simple command to run on Unix systems that will check the time
    and optionally drift compared with a known, local and reliable NTP
    time server.  No privilege is required just to read the time and
    estimate the drift.

    A client for Unix systems that will synchronise the time from a known,
    local and reliable NTP time server.  This is probably the most common
    one, and the need that caused the program to be written.

    A server for Unix systems that are synchronised other than by NTP
    methods and that need to synchronise other systems by NTP.  This is
    the classroom of PCs with a central server scenario.  It is NOT
    intended to work as a peer with true NTP servers, and won't.

    A simple method by which two or more Unix systems can keep themselves
    synchronised using what is becoming a standard protocol.  Yes, I know
    that there are half-a-dozen other such methods.

    A base for building non-Unix SNTP clients.  Some 3/4 of the code
    (including all of the complicated algorithms and NTP packet handling)
    should work, unchanged, on any system with an ANSI/ISO C compiler.


As I read this, it was intended to sync from a "local and reliable NTP
time server". I take this to mean that synchronizing to a remote server
over a probably bandwidth-starved home cable or adsl link is not really
msntp's league.

Also, if you have a bunch of m0n0walls, you probably won't be able to let
them sensibly peer.

Finally, you won't be able to use local reference clocks (important in
standalone configurations).

msntp just seems too limiting a choice for such a great universal network
plumbing box as a Soekris with m0n0wall and the alternative choice, proper
ntp, is not very costly in terms of space, and also not any more difficult
to implement.

my 0.02