On Mon, 16 Jun 2003, Michael Mee wrote:
> 
> Here's my proposal for time support. I'm trying to get a _simple_ version of
> the following implemented and sent to Manuel as a set of diffs by the end of
> tomorrow. Using it will be the real test, but here's a quick preview in the
> hope someone has suggestions/advice/insights.
> 
> Broad details:
> + found msntp which appears to work on the Soekris and takes 38k - sntp
> client and server!

Yes.  You need separate instances for client and server, but if it's
sharable there's still only one copy of the code.

> (See http://www.freebsd.org/cgi/url.cgi?ports/net/msntp/pkg-descr) (vs >200k
> for ntp)

I've actually made a number of fixes to msntp, although I need to
coordinate the changes with the author.  Beware that the multi-server
feature introduced in V1.6 has a lot of problems, and also that the server
side isn't compatible with all clients.  I suspect the latter is due to
inadequate precision in echoing timestamps.  It's compatible with itself
because it never *checks* the echoed timestamp, which causes it to get
really badly confused by duplicate responses.

> + I'll enable it as daemon to keep clock updated, optional as server (see
> below)

The client/daemon side needs to be optional as well, since it needs to be
pointed at a server to be useful.  Also, running the server side without
the client side doesn't make a lot of sense, since the accuracy of the
Soekris battery clock is horrendous.

Unfortunately, msntp also tends to be rather "fragile" in the presence of
network errors.  Most systems that use it in daemon mode arrange to
periodically restart it from cron, but then of course you need cron. :-)

> + need to give the OS a timezone to work effectively (or else use GMT
> always, yuck)

Correct.  Even though [S]NTP itself is UTC-based, some other uses of time
like to be local.

> + will use web page drop downs to help user build valid posix timezone
> specifier
> + add new entry on main settings page to set timezone (system.php)
> + new entries in <system> section of config.xml, e.g.:
>       <posix-timezone>AEST-10AEDT,M10.5.0,M3.5.0</posix-timezone>
>       <time-update-interval>300</time-update-interval>

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.

When the battery clock is set to UTC (as it normally would be on a Soekris
box), it's imperative to remove /etc/wall_cmos_clock when installing a
non-UTC timezone.  Otherwise, adjkerntz thinks the battery clock is set to
local time, and screws things up.  Even if you think you can avoid this by
setting the timezone "too late" for adjkerntz, that doesn't work because
adjkerntz "lingers" and sets the battery clock at shutdown time.

For systems that *do* (unfortunately) keep the battery clock in local time
(e.g. PCs that need to also run Windows or DOS), the file
/etc/wall_cmos_clock *does* need to be present, *and* the correct timezone
needs to be established before adjkerntz runs (at the latest).  My setup
includes copying /conf/wall_cmos_clock to /etc at boot time, knowing that
the copy may fail, but this approach demands that the file *not* be
present in the mfsroot image.

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
doesn't exist yet, but even if it's done "manually" it only has to be done
once (i.e. it survives firmware upgrades).

> for timezone and how many minutes between forced clock updates - 0 for never
> + new link under Services to configure optional time server details
> + new entry in <m0n0wall> section for sntp server control:
>       <sntp>
>           <enable />
>           <timeserver>time.nist.gov</timeserver>    // space delimited list
>           <broadcastinterval>0</broadcastinterval>   // 0 or omitted means
> never
>       </sntp>

The server mode and the broadcast mode are distinct, and require separate
instances of the program (neither of which can also be the client).  
However, the broadcast mode is mostly not worth bothering with, since the
client has to wait for a broadcast before obtaining the time, and then
gets poorer accuracy due to the lack of network delay compensation.

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
the improved accuracy one gets from a "close" server.  Theoretically, if
your ISP offers NTP sevice, that should be more accurate than going "over
their heads", although sometimes that's not the case if they've made poor
peering choices.  It might be marginally acceptable to have a default
server for a one-time synchronization at boot time (which is still a huge
improvement over the battery clock), but ongoing synchronization should
demand an intelligent choice of server(s).

BTW, one of the many problems with msntp's multi-server mode is that it
fails if *any* specified server doesn't respond reasonably.

> Random details:
> + sntp = simple ntp - relatively new addition to ntp standard, but broadly
> supported

Only if you consider 1992 to be "relatively new". :-)

> + modern style timezone setting by country/city requires 800k - no way!

No - see Manuel's post.

> + possibly add the file /usr/share/zoneinfo/posixrules to provide default
> USA daylight savings (hate to be US-centric but that's what the posix
> standard defaults to and there's slightly bizarre behaviour if we omit it -
> see my PS below)

Maybe.  See below.

> + msntp barfs on WinXP's built-in braindead time request, but it will be
> simple to patch (according to its author) - next version!

That may not be the only issue, though.

> By choosing TZ as POSIX compatible we take up minimal space but add
> complexity for users to specify the daylight saving info. We could
> additionally prompt for common daylight savings rules and build it for them
> (e.g. http://webexhibits.org/daylightsaving/g.html has a good list), but
> I'll start simple!

You don't want to literally use "TZ" at all.  Most modern Unix systems
don't even define TZ by default.

> PS: It was a real pain to work out the timezone details. I couldn't get the
> TZ setting to be recognised at all. At first I thought it was a problem with
> php not exporting the environment settings correctly (PHP putenv() doesn't
> imply export/setenv), but it wasn't. I eventually worked out that setting
> TZ=PST8 worked, while TZ=PDT8PST failed (i.e. date showed GMT). It turns out
> unless you either have a /usr/local/shared/posixrules file or a full
> daylight savings rule spec in the TZ or NO daylight savings specified (e.g.
> PST8), then date (etc.) defaults to GMT. Makes sense - afterwards :-)

Well, if you really specified "PDT8PST", then of course it didn't work
because it was backwards.  Normally, "PST8PDT" is an alias for
"US/Pacific".

Note that POSIX is brain-dead in demanding the "DST rule" format, and
doesn't officially allow the zoneinfo-style spec unless you put a colon on
the front to indicate "nonstandard".  However, most real-world Unix
systems accept it without the colon as long as the specified zoneinfo file
exists.

Aside from being ugly, the POSIX scheme is just plain incapable of working
correctly, since the system is supposed to be able to convert *any* UTC
value (within range) to the corresponding LT (and vice-versa), which
requires the complete *history* of DST rules, not just the present
version.

On Tue, 17 Jun 2003, Manuel Kasper wrote:

> > + modern style timezone setting by country/city requires 800k - no way!
> 
> Hmm, last time I checked, /usr/share/zoneinfo could be .tar.gz'ed to about
> 70 KB... I guess it would be pretty easy to call tar from PHP to extract a

Yes, and I'm not sure the 800K figure is really correct even withot
compression, since there are quite a few aliases that use use links.

> specific zone file (maybe the list of available zones would have to be
> kept in a separate text file for convenience). OK, we'd have to include
> tar, but built as a dynamic executable (not static as by default), it
> shouldn't be bigger than about 100 KB either. So I think 220 KB (including
> msntp) would be a fair tradeoff to get full timezone and NTP
> functionality. And we might need tar for something else in the future
> anyway. You might want to give this a try...

Yes, I already noticed that if you want to FTP a file over and preserve
its timestamp, you have to use gzip since tar isn't there. :-)

> AFAIR you wouldn't have to mess with TZ that way - just copy/untar the
> appropriate zone file to /etc/localtime, and that should do it.

Yes and no.  As noted above, you really want the timezone set up early, so
you want the selected zoneinfo file already available.  The untar/copy
stuff would be part of the process to *set* the timezone.  A *single*
zoneinfo file isn't big enough to worry about storing more compactly.

					Fred Wright