Re: NTP and TAIClock??

2003-07-01T17:55:20 Ed Vazquez:
> I'm wondering if there are any extensions that will allow me to use
> TAIClock to send/respond to NTP as well as TAI.

I started to answer that question (A: no extensions needed,
different components can be mixed-&-matched), but then realized that
you really have a different question at the heart of matters.

> Within my environment, there are a multitude of devices (network gear,
> Winboxen, etc.) that do not and likely cannot understand the TAI
> protocol.  What I have found is that running NTP and TAI on the same
> device causes all kinds of clock errors as NTP is not as accurate (and
> requires an NTP signal provider or it fails, etc.).
> 
> I wanted to run TAI on one server, and NTP on another, but budget
> concerns are forcing my hand and I will have to consolidate.

I _think_ you've confused two very separate issues.

There's the network protocol, and there's the actual timeline.

One server can synchronize off either taiclock or NTP network
protocols to lock its clock; and one server can publish views of its
clock over both taiclock and NTP network protocols.

But there's only one system clock, and the clock-sync tools
rendesvous through it.

That clock can run on the TAI timescale, where you use the right/
zones in the zoneinfo database, and every real-world second the
clock advances one second. All times within the Unix epoch are
unambiguous, and there are no discontinuities in the timeline. And
devices like routers that sync off your NTP-protocol view of
TAI time, and turn around and spit text messages back with text
timestamps in protocols like syslog, will be some offset (if I'm
remembering right it's currently 22 seconds) off, and that offset
will change if there's ever another leap second.

Alternatively, if you've got one server, its clock can run on NTP
time (and again, you can publish via NTP and taiclock protocols). In
that case, you've got discontinuities in the clock itself --- it is
jumped to cope with leap seconds, since POSIX brilliantlty denies
that such things exist. It's ugly, but that's what you have to have
to get correct timestamps reported by appliances that can't be told
to use right/ timezones.

If you had two servers --- and a $200 junker PC would work fine for
the job of being the second server --- you could run one master time
server, then use a network sync protocol to synchronize the second
server, but run its clock on the other timeline, and have them both
publish views of their clocks. Synchronize all your programmable
devices with taiclock from the machine with the TAI system clock,
and synchronize the non-programmable appliances via NTP from the
machine with the NTP system clock. Everybody will be doing the best
they're capable of.

-Bennett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/Ag5mHZWg9mCTffwRAlGNAJ9VeTFzegoSxMkBt49b3r3N3nNAOgCgwLps
yK2eupdxe3nHhIBjoih1BcA=
=HZqJ
-----END PGP SIGNATURE-----