[ previous ] [ next ] [ threads ]
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Re: time client/server proposal - comments please
 Date:  Thu, 19 Jun 2003 20:03:30 -0700 (PDT)
On Wed, 18 Jun 2003, Bart Smit wrote:
> On Wed, 18 Jun 2003, Fred Wright wrote:
> > Well, some of us are picky about timestamps. :-)
> I always try to circumvent a lot of the adjkerntz-like issues by *always*
> running the cmos clock on UTC, and not bothering too much with the local

That's certainly the best approach, but sometimes legacy issues get in the
way.  I wouldn't expect it to be much of an issue on a 45xx, since Windoze
won't run on it and I expect very few people want to run DOS on it, but a
real PC can be a different story.  Thus I figure it's worth grudgingly
supporting the LT-based RTC.

It would of course be best if the BIOS actually kept the timezone
(including a DST flag) and an indication of whether the RTC is set to LT
or UTC.  Then, any "enlightened" OS could obtain the flavor of time it
wants in either case, and the choice would be based on which
"unenlightened" OSes one wants to run.  But the BIOS designers didn't
think that far ahead.

> timezone unless necessary. The general rule is:  "all times refer to UTC
> unless otherwise specified". Since so many applications don't state the TZ
> (or even give misleading information), this often implies the use of UTC
> at the "user end" as well.

Just because it doesn't say doesn't mean that it's UTC.  For example, the
TCP and UDP "daytime" service has a completely unspecified format, but
most systems report LT in daytime, and there are even daytime-based sync
programs that expect that.

> So, having the system clock on UTC is pretty much mandatory; having the UI
> on local time is not always wise. Since m0n0wall is not supposed to have
> lots of user interaction anyway, I would not use local time on it at all.
> However, I do think it's a Good Thing to have the possibility. :-)

If there were a way to set the time manually, it would be more useful to
use LT there because most people don't set their watches to UTC, so it
saves having to convert (possibly erroneously).  But the delays involved
in the WebGUI make it a poor way to set the clock, anyway.

> > [...] 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. :-)
> I don't know any clock *cards*, but I'm using the Rockwell Jupiter GPS
> receiver unit, which can easily be interfaced to the second serial port of
> the 4501.

I thought about that approach (and could even try it out with my GPS
handheld), but I wouldn't expect very good accuracy from it.  First of
all, most systems don't worry very much about keeping serial-port latency
down to a dull roar.  More importantly, if the timing accuracy for the
NMEA output is as awful as it is for the LCD update (in my Garmin, at
least), it would be totally unacceptable.

The Garmin receiver updates the display once per second, but makes no
attempt to synchronize that to UTC/GPS second boundaries.  In addition,
there's a significant minimum delay that I estimate to be somwehere in
the 100-200ms range.  Thus, a receiver that internally knows the time to
sub-microsecond accuracy can't even manage to display it within one-second
accuracy, just because they didn't think it was important.  I could easily
see the same philosophy being applied to the NMEA output, though I haven't
actually tried to measure it.  In contrast, I believe I can measure the
time offset of my wristwatch to within about 25ms.

The GPS PCI cards typically specify one-microsecond timing accuracy, so
they *do* understand the problem (though 100-microsecond accuracy would be
good enough to insure it isn't the limiting factor).  But they're
typically overkill, being complete self-contained GPS receivers, with
extra ports for DGPS and/or IRIG conections, as well as using
oven-stabilized crystals (i.e. power hogs), and they want +/-12V as well
as +5V.

Obviously handheld GPS receivers get by with *very* little power, but then
they tend to tell time poorly for unrelated reasons.  A Soekris box with a
suitable 3.3V GPS clock could make a very economical primary NTP server.

On Wed, 18 Jun 2003, Michael Mee wrote:

> > Don't all modern systems have adjtime?
> > Making step adjustments is a bad idea;
> Switching to adjtime is easy - though when I switch to that I need to add
> some way to force an update to the current time for the initial setup when
> the time is off by hours (years!). Hmm, like most things, more of a user
> interface/design issue than a technical problem...

That's a problem with or without adjtime, since msntp will ask for
confirmation before making a "large" change, anyway.  The cheap fix is to
require the user to set the clock approximately correctly in the BIOS
dialog before enabling NTP.

> Fred thanks for detailed responses. Very helpful to a ntp newbie like
> myself!  When you get hold of my changes I welcome your ideas. This is very
> much v1!  Its much easier to critique, and fix, a specific implementation
> than a theoretical one :-).

Well, even without looking I can tell you what I did to make it *use* a
configurable timezone, though I hadn't provided a way to set it.  I think
this is a better approach for reasons I've already stated.

I basically made 4 changes, 2 mandatory and 2 for "niceties":

1) Removed /etc/wall_cmos_clock from mfsroot.

2) Made the following addition to /etc/rc (two original lines shown for

	<# mount other file systems (notably /conf)
	<mount -a

	># mount other file systems (notably /conf)
	>mount -a
	># Install timezone files from /conf
	>cp -fp 2>/dev/null /conf/localtime /etc/
	>cp -fp 2>/dev/null /conf/wall_cmos_clock /etc/

The copy commands silently fail if the source files are absent, so it's
fully compatible with existing setups.  If the first one fails,
/etc/localtime from mfsroot is left untouched as the default.  If the
second one fails, /etc/wall_cmos_clock is left absent, as it usually
should be (but I wanted to allow for the possibility of the LT-based RTC).  
Note that /etc/rc.firmware *already* preserves /conf/* across firmware
upgrades (but see #3 below).

The 2 "nicety" changes are:

3) Added "-p" to the two "cp" commands in /etc/rc.firmware that preserve
the config file(s) across firware upgrades.  This doesn't specifically
relate to timezones at all; it just says that upgrading the firmware
shouldn't clobber the timestamp(s) of the config file(s).

4) Replaced /etc/localtime with a copy of zoneinfo/UTC instead of
zoneinfo/GMT, since the former is "more official".  This only affects the
ASCII name of the zone, not the time value.

In this scheme, what's needed to set the timezone is just something to
copy the proper zoneinfo file to /conf/localtime (surrounded by the
config_mount_rw()/config_mount_ro() as usual).  I personally don't see any
need to put it in the XML file at all, but if one wanted to make the
latter the primary source of the setting, then the code to copy the
selected zoneinfo file to /conf/localtime could be part of write_config().  
It should be copied to /etc/localtime as well in order to take immediate
effect, and I'd use -p everywhere so you get the timestamp of the original
zoneinfo file.

This latter part is probably pretty similar to what you're already doing,
but with some of it in a different place.

					Fred Wright