[ntp:questions] Re: Arcron DCF77 ref clock driver: problem with timezone and UTC

Eric Voisard evoisard at MAPS.ON.ieee.org
Wed Mar 23 13:51:49 UTC 2005


Hi Ronan,

"Ronan Flood" <ronan at noc.ulcc.ac.uk> wrote in message
news:d1p68l$mgi$1 at canard.ulcc.ac.uk...
> The driver (refclock_arc.c) uses the command "o" (0x6f).
> DCF support was grafted onto this driver by later hands, originally
> it supported only MSF, which is GMT/BST.

Yep, the "o" command, thus the time returned is CET.
The HKW (and all Arcron clones I guess) also has the "e" command which
provides the same but in UTC.

> > Here's what is said about the flag1: "If set to 0 (the default), the
clock
> > is set to UTC time. If set to 1, the clock is set to localtime."
> >
> > I interpreted this as an information for the driver (which might have to
> > work with different time codes): 1 => the driver must translate to UTC
the
> > obtained time, 0=> the driver can work "as is" with the obtained time.
>
> That's how I read it too.

And apparently that's how it works. Yesterday I tried toggling the server
between UTC and CET timezone and played with flag1. Here is what I got:

Timezone    ->    ntpd     =>    status
1) UTC    ->    flag1=0    =>    fail (offset ~1 hour)
2) UTC    ->    flag1=1    =>    fail (offset ~1 hour)
3) CET    ->    flag1=0    =>    fail (offset ~1 hour)
4) CET    ->    flag1=1    =>    success (offset ~0 hour)

If the server's timezone is CET, the driver and ntpd work as expected.
When the timezone is UTC, it fails in any case in a way that I think is
dubious, it should not fail in 2).
I've played with other timezones as well, in example US/PST, but if the
shift is too large, ntpd oddly fails to reach the clock (status= 8xxx)...
It works within the range GMT-2 to GMT+5, but the offset increases in one
hour increments. ntpd considers them all insane, except GMT-1 which is CET.

Well, the is something odd. Either in the way the driver passes the time to
ntpd, or in how and where ntpd gets the computer's actual time (rtc,
system,...) ............

> > As DCF77 is in CET/CEST format, then I would say the driver has to map
what
> > it gets to UTC, or it has to ask for the time in UTC...
>
> Indeed, depending on the capability of the clock to adjust its output
> to UTC.  Of course one wonders why your host timezone is GMT not CET?

:-)
It's because all the work done by this server and all records have to be in
UTC time.

> One approach you could try is to adjust the time1 fudge factor,
> "fudge 127.127.27.1 flag1 1 time1 -3600".  This is a hack and not
> the right way to solve the problem, but might work ...

This is a pretty good idea, and it works! Thanks!
Maybe is it a hack, but if we let cleanness aside and as it fixes what I
think is a bug, then it's ok. I'm getting what I need. Though I think I'll
open a bug to the NTP's Bugzilla and see...

> If your clock needs a command other than "o" to return UTC, it would
> be possible to modify the driver to send that (and expect it to be
> echoed back) instead.  This could perhaps be made conditional on
> fudge flag4, which the driver doesn't use otherwise.

I though about it: simply replacing the "o" with an "e". I wish I had
time...
Though my HKW has same command set as the Arcron (e.g. "o" exists and does
the same) since from what I understand, only the case changes. So, all
Arcron should behave like my HKW, at least on Solaris/SPARC...

See you, Eric





More information about the questions mailing list