Re: NTP and TAIClock??

Well, sort of.

Looking at my question, I see that I did not ask it correctly.  Here
goes with a second try.

I have:

~150 MS Windows servers
20 HP-UX servers
2 IBM AS-400 (AIX)
~2000 Network devices (Cisco, but there are some Bay and 3Com legacy
  boxes out there)
12 Telecom switches (8 Nortel, 4 Lucent/Avaya)
~5000 MS Windows workstations (they use the NET TIME settings to point
  to their respective Domain Controller)
3 Payroll timeclock devices running the TIME protocol across 110/AC via a
  Simplex SNTP convertor
1 "Standardized" clock used to mark birth and death times
6 IDS sensors in various places
2 IDS analysis consoles, one for strict IDS data, the other for all
  device logs (syslognt for the Winboxen)
12 Cisco PIX firewalls is various places

Up until I came on board about a year ago, all devices were pointing
to their own time clock, depending on which technician installed them,
etc.  The payroll timeclocks weren't even that good, they were set
twice a year by the Electrician Supervisor using his wristwatch.

I got NTP up and running right off the bat and resolved a lot of the
issues within the network (some items were _decades_ off).  Recently
though, I have been trying to move server class, network and IDS gear
to a more accurate standard to improve the chances the organization
has in showing that the data collected is _legally_ intact should we
ever be so unlucky as to have to prosecute or defend (which of course
means I can't have the 22 second variance - ever try to explain
technology to a "jury of your peers"??).

Now here's the kicker.  We're a public hospital.  With the general
economy, there is exactly one person dealing with this issue (me) and
I have a working budget of $0.00USD.  There are no surplus machines,
etc. so I have to re-use what I have.

The Cisco devices are the real kicker.  For whatever reason (and Cisco
TAC doesn't have a good answer) they won't sync to a clock that is
less accurate than Stratum 3 (e.g.: Stratum 4+) and they don't do the
TAI protocol.

So, somehow I have to either get my NTP service to look at the system
clock and consider itself at least S3, or I have to find a
patch/extension for taiclockd that will also allow it to
broadcast/respond on the NTP protocol/port.

I really appreciate any help folks can throw my way.

-- 
Ed Vázquez

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A little government and a little luck are necessary in life, but only
a fool trusts either of them. - P.J. O'Rourke

On Tue, 1 Jul 2003, Bennett Todd wrote:

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