On Tue, 17 Jun 2003, Manuel Kasper wrote:
> On Tue, 17 Jun 2003, Fred Wright wrote:
> 
> > No, you don't want to rely on the XML file for that, since it's desirable
> > (and even absolutely necessary in certain circumstances) to have the
> > timezone set up as early as possible in the boot sequence.  The proper way
> > to do this is to keep a /conf/localtime that gets copied to /etc as soon
> > as /cf is mounted.
> 
> Oh come on, if we do it before any other daemons are started (i.e. early
> in rc.bootup), I don't see where that would leave us with major problems
> (does anybody care about the timestamp of e.g. the /var/run directory?).

Well, some of us are picky about timestamps. :-)

Actually, there are some real not-so-esoteric issues, including:

1) Any logfile that includes a textual timestamp is almost always
sensitive to the timezone, and some logging starts very early.

2) In the case where adjkerntz is actually changing the time (due to the
battery clock's being set to local), that's actually a potentially
dangerous operation.  Due to fundamental brain-damage in Unix, most timing
of intervals is done on the basis of "system UTC", and suddenly changing
"UTC" by a few hours is playing "Russian Roulette" even under the best of
circumstances.  This is especially risky for Eastern longitudes, where the
adjustment is negative.  There's really no way to use the adjkerntz
approach with 100% safety, but at least one should minimize the risk by
running it (with the proper timezone) as early as possible in the boot
sequence, when there's as little as possible "going on".

> Sure, adjkerntz is invoked in /etc/rc, but that could be moved to
> rc.bootup (after the /etc/localtime setup) as well. Is there anything else

No, see above.

OpenBSD is even more paranoid about this issue, to the extent of having a
kernel configuration parameter to specify the UTC offset of the battery
clock in order to insure that the time gets set correctly from the
start.  Unfortunately that means it has to be adjusted for DST changes,
although that's one of the parameters that can be changed without a
rebuild.

Linux's "hwclock" does the equivalent thing somewhat later in the startup,
but then that's Linux. :-)

> in m0n0wall's /etc/rc that could interfere with (later) timezone setup? I
> really like the idea of having config.xml as the only variable in m0n0wall
> - great for backup/restore, too...

While the single XML file has its benefits, I see no reason to turn it
into a "holy grail".  Backing up a few files from a single directory isn't
much more difficult than backing up a single file (in fact, the firmware
upgrade already preserves the entire directory; my only tweak there was to
preserve the timestamp(s) in the process), and in any case it's not as if
the timezone changes so frequently that it needs to be included in a
regular backup schedule. :-)

I also don't see the point in performing a computation on every boot that
only needs to be done once.  Elementary efficient programming dictates
that computations be moved "outside the loop" wherever possible.

> > I already worked this out and sent the (trivial) changes to Manuel, but
> > they haven't made it into the releases.  The part to *set* the timezone
> 
> I put that on hold because I thought we'd better wait until we have webGUI
> support for it, so it will all make sense.

Well, yes, but the changes are haramless if you don't actually have a
/comf/localtime, and 3 of the 4 changes are good on "general principles".

On Tue, 17 Jun 2003, Bart Smit wrote:
> 
> Oops, forgot to CC the list.

See. :-)

> 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:

Well, yes and no.

[...]
> </quote>
> 
> 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.

That's not strictly true, but indeed it doesn't have the sophisticated
averaging that "real NTP" does.  Though "real NTP" works in a way that
makes sophisticated averaging more necessary (see below). :-)

It's more problematic as a server than as a client, especially since it
always advertises 0 dispersion, which causes any client that uses it to
have an overoptimistic view of its accuracy.  The standard version also
ignores the server's dispersion (as client), though I've fixed that.

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

True.  Msntp doesn't operate in peer-to-peer mode at all.

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

Also true.  Though if someone's found a GPS clock card that actually works
with the power available in the net4501 I'd like to hear about it. :-)

> 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.

I think the biggest drawback to "real NTP" is the configuration
hassle.  It's much more complicated to set up correctly, and it can screw
up really badly if you do it wrong.  SNTP is more "obvious", and some of
its more egregious limitations are fixable.

One of the difficulties with msntp is that it has no support for the
"advanced kernel clock" features added to typical modern Unices in support
of NTP.  That means the *best* it can do for rate correction is the
"adjtime" kludge, which is better than step adjustments but far from
ideal.

Oddly enough, there's one way in which msntp is algorithmically superior
to "real NTP", namely that it uses straightforward round-trip exchanges
for time transfer.  NTP seems to have been designed around some archaic
notion of bandwidth constraints, and *never* does round-trip exchanges
between peers.  Instead, all transactions are one-way, with the
higher-level processing being responsible for deriving "round-tripness" to
take network delays into account.

On Tue, 17 Jun 2003, Michael Mee wrote:

> FYI, I've sent V1 to Manuel. If someone wants a private image or diffs
> before then, shoot me an email.
> 
> Final v1 implementation was (** shows changes from previous email):
> 
> v1 - setting/updating the clock and adding timezone support
> + dropdown(s) in system.php to allow selection of region/city
> + use a tar.gz file as a source to create /etc/localtime file as soon as is
> practical on boot **> before any network setup in rc.bootup

Grumble.  See above.

> + config.xml additions under <system> are (with example values):
>       <timezone>Etc/UTC</timezone>  // ** new default

I agree that "UTC" is a more appropriate default than "GMT".  POSIX
regards GMT as "official" and UTC as "nonstandard" but those guys seem to
be out of touch with real international standards.  Also, if you want to
get *really* picky, GMT isn't *quite* the same thing as UTC, but in most
contexts it's used synonymically (and in the zoneinfo case, the *only*
differnce between "UTC" and "GMT" is the name).

>       <time-update-interval>300</time-update-interval>    // 0 means never
> run as client
>       <timeservers>pool.net.org</timeservers>  // ** no hyphen
> + On fresh install run msntp in client mode to update the time every 5
> hours, but user can set update interval to 0 to disable it. For a firmware
> upgrade in which case it will be 0 so the user has to explicitly enable it.

Are you saying that it has to be reenabled after a firmware upgrade?  If
so, I don't see why.

> ** I did NOT auto-update anything in config.xml. The clock will not start on
> boot UNTIL you go to system.php and press save. At that point, the displayed
> default value of 300 will be used and the msntp program will immediately
> reset your BIOS clock to UTC

What do you mean by "BIOS clock"?  Msntp doesn't change anything but the
time in the currently running system.  The resulting time will be
propagated to the battery clock by adjkerntz on a normal shutdown, but
that's a separate issue.

> + include the standard msntp release in /usr/local/bin ** no patches,
> standard release
> + set the default time server to pool.ntp.org (see
> http://fortytwo.ch/time/), with the user option to change it on the
> system.php ** fixed typo in previous mail (was net.org)
> + remove the existing /etc/wall_cmos_clock file ** also remove localtime as
> we create it on startup (actually links to the single extracted file in
> /usr/share/zoneinfo/xx/xx)
> + add tar to /usr/bin ** done, but I just used the standard statically
> linked version. I expect Manuel will use a smaller dynamically linked &
> irrelevant options removed version
> + I haven't determined if adjtime works appropriately so I'll have msntp use
> settimeofday for now (obviously trivial to change later) ** yes, used the -r
> option

Don't all modern systems have adjtime?

Making step adjustments is a bad idea; it's kind of the "little brother"
of the huge LT/UTC change that I referred to above.  The problem is that,
from the beginning, Unix has had the philosophy of using UTC-based time to
measure intervals.  That means that adjustments to the time screw up those
measurements.  This is especially bad when the corrections are negative,
since activities may then appear to take 0 time or negative time, which
can *really* screw up some calculations.  There's a certain "crap
shoot" quality to it, as one can often get away with it, but that doesn't
make it reliable.  Monotonicity of time is a ubiquitous assumption that
one *really* shouldn't violate.

Interestingly enough, the whole adjtime thing was actually derived from a
kludge whose original purpose was to "make up for lost time" due to missed
clock interrupts.  It morphed into a way to make limited adjustments to
the time while maintaining monotonicity and differentiability, but within
limits.  And it's still not a great solution, since it causes a small
error in any rate measurement made while it's in effect, but it's better
than the step adjustment approach.  Its biggest limitation is that it
can't handle a new adjustment's being requested befpre the old one is
complete.

Many newer systems support a mechanism to actually inform the kernel of
the rate error in the clock, and thus keep the time more or less correct
continuously, but I believe only "real NTP" supports using this.

> Visually the big difference is the opening 'System -> General Setup' page.
> It now has 3 more entries: Time Zone with a nice drop down of all
> region/city combinations, Time Update Interval and NTP Time Server.
> Clicking Save will immediately change the system time zone and [re]start
> msntp. You can confirm the time zone by viewing the "Status -> System" page.
> I hoped to add something to Diagnostics->Advanced to provide some msntp
> debug info, but didn't get to it, sorry. In the interim you can go to
> http://10.0.0.1/exec.php and use
> /usr/local/bin/msntp pool.ntp.org
> to confirm its working. You can use a -v, -w or -W option to get increasing
> amounts of debug info.

I think you mean "-v, -V, or -W"; there's no "-w".  Note that -W screws up
the timing significantly.

On Tue, 17 Jun 2003, James Braid wrote:
> On 6/17/2003, "Manuel Kasper" <mk at neon1 dot net> wrote:
> >On Tue, 17 Jun 2003, Fred Wright wrote:
> >> I don't think including a default server is a good idea.  The admin might
> >> get annoyed if everyone on the planet started using that one particular
> >> server because nobody bothered to change the setting. :-) Not to mention
> 
> pool.ntp.org has been setup for this purpose as I understand it...basically a
> round robin of a lot of public stratum2/3 NTP servers, meant for use where
> you just want "good enough" time sync.

Probably better than nothing, although picking something "close" will
usually do quite a bit better.  Also note that, although most of the NTP
documentation talks about keeping "ordinary slobs" away from stratum 1
servers, the advent of cheap GPS clocks has actually made a number of
unrestricted public-access stratum 1 servers available.

> But yes, a firewall should have a very minimal set of default services. The
> commercial firewalls I have used (Netscreens mainly) all have NTP disabled by
> default. They display a banner when you start them up the first time that
> reminds you to set the clock though.

For maximum paranoia, yes.  But unless you want to have two or more such
devices on your network, one box has to do multiple duties as a firewall
and as a general "network resource", providing a number of additional 24/7
services without benefit of rotating memories.

					Fred Wright