Experimental Physics and
Industrial Control System

[email protected] (John R. Winans) · Thu, 23 Mar 1995 18:33:48 -0600

>The problem I have is that I have a GPS clock on a VME crate and
>want to serve time from there to other VME crates, Vaxes and Suns on
>the network. It is particularly important that one Vax, in particular,
>has a pretty good knowledge of the time.

I think the APS would like to do a similar thing, I have written a driver
for a GPS board that has a pretty nasty interface on it.  Given that it looks
as if it was made in 'Joe Nobody's Basement Board House' I did not stop too
long to wonder why.

The trouble I had is/was:

	The device ONLY provided the number of milliseconds into the current
	calander year.  Therefore I could not figure out what year it is.  A 
	rather nasty problem for an IOC that should otherwise be self contained.
	I figure that I could always ask a Unix box for the time and assume it is
	close ehough to get the year right.  

	This also posed a problem with the handling of leapseconds -- not that 
	they exist... but how to represent them on a system that does not account 
	for them -- EPICS.  You see, sice EPICS keeps the time in nanoseconds
	since 1990, and the GPS does it since last New Year's eve... how do I
	figure out time it was (in EPICS-speak) at midnight last New Years eve?
	The days*24*60*60 plus leap years is simple, but how many leap seconds 
	passed since then... they should be included because otherwise 
	there will be a one-second loop in time at midnight on new years eve if
	there was one encountered in the past year.

	Even if that was settled, how does EPICS deal with the time stamps?
	EPICS does not know squat about leapseconds and therefore does not account 
	for them at all.  This is not TOO bad... your timestamps will be right,
	but EPICS tools will simply print them wrong... at least they will be
	in order.  However, if you are unfortunate enough to have to correlate
	times from two different IOCs, and only one knows of leaps, its point
	of reference (in my case, last New Year's) would be different than the
	other and therefore run 'off by N' seconds.

	I have looked (a little) at the NTP specs and can not find any way
	to 'ask' another machine if and when leap seconds have occured.  Without
	that knowledge we are kind-a stuck.

	I have considered recommending a change to EPICS in that its time stamps
	be represented as year and nano-within-year.  This way, we don't have to
	worry about leapseconds prior to the current year.  This way the base
	reference calculation will never have to worry about leaps taken between
	the base reference time (1990) and last New Year's.

	Say... how do the big GPS fans retain this leap second count information?
	I know that the UNIX date routine has the number of leap seconds since
	1970 (the real UNIX base reference) hard-coded in the date routine
	source code (I think 14 last time I checked.)

>I was thinking of running the VxWorks port of Xntpd on the VME crate
>and then using that as a time server for all the network. The questions
>I have are:
>
>1. Can I do this?

You should be able to do so.  I have seen type of client-only ports on NTP 
available for vxWorks. It would be nice to know that a server exists and works.
Please forward any experience with it.

>2. How do I integrate this into the Epics/vxWorks time support?

See Jim's reply note.

>3. Has anyone done anything similar?

Thought about it, never tried an NTP server.

>4. What are the problems involved?

EPICS lack of leapsecond knowledge.

--John

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System