Re: GPS-UTC Leap Corrections

cjc wrote:
We have some time servers with GPS clocks. One of their uses is in
operations centers where satellites are being flown. The satellites
use
GPS (as opposed to UTC) internally, so we want the computers on the
ground also to use GPS (rather than UTC). The time servers speak NTP
and hand out GPS time as if it were UTC. The ground computers think
they are on UTC, but it's really GPS.

But we'd like some of the computers to really be on UTC. I really
haven't
been able to think of a good way to have computers use the GPS time
given out by the time servers as a source, but then to actually offset
their own time by the GPS-UTC difference. Some quick Googling hasn't
turned anything up. Anyone have some suggestions on how to manage
something like this? Or are we just going to have to live 15 seconds
ahead of the rest of the world?

This is one more vote for my long-standing request for the ability to use the 'fudge' command on real (network) servers, and not just refclocks.

It is relatively easy to do, it just means that you have to add/subtract the required offset when handling all times from the relevant network server.

I.e. when server utc1 asks gps1 for the time, it needs to do the following:

1) Do a completely normal t1/t2/t3/t4 NTP request and calculate the resulting offset.

2) Adjust the offset from (1) by adding/subtracting the fudge time.

3) Use the resulting value as in the current code.

I.e. only step 2 is new.

You do have to make very sure that none of your GPS-based servers will ever serve time to normal ntp clients, that would really mess them up!

Terje
PS. The easiest (and also ugliest!) hack would be to take the ntp source code and add a single line to the server clock calculation code where you add the current offset. You _must_ recompile/fix this value on every upcoming leap second though!
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
.

Relevant Pages

  • Re: GPS-UTC Leap Corrections
    ... GPS (as opposed to UTC) internally, so we want the computers on the ... and hand out GPS time as if it were UTC. ...
    (comp.protocols.time.ntp)
  • GPS-UTC Leap Corrections
    ... We have some time servers with GPS clocks. ... GPS (as opposed to UTC) internally, so we want the computers on the ...
    (comp.protocols.time.ntp)
  • Re: Extra leap seconds due to earthquake?
    ... > internationally-agreed extra leap second or seconds that are sometimes ... > On the GPS front, I think that GPS internal system time (UTC as at ... > satellites) is now 13 seconds ahead of today's UTC, ... It is expected that Celestial Pole offsets related to the IAU1980 Nutation ...
    (sci.geo.satellite-nav)
  • GPS CONSTELLATION STATUS -- Fri Sep 9 12:22:15 UTC 2005
    ... Scheduled Coordinated Universal Time (UTC) Time Step ... GPS will not be adjusted physically. ... Change to GPS Broadcast Navigation Message On June 2, 1995 beginning approximately 1900 UT, the GPS Master Control Station began adding data to the spare data fields in the broadcast navigation message. ...
    (sci.geo.satellite-nav)
  • GPS CONSTELLATION STATUS -- Wed Sep 28 12:06:44 UTC 2005
    ... Scheduled Coordinated Universal Time (UTC) Time Step ... GPS will not be adjusted physically. ... Change to GPS Broadcast Navigation Message On June 2, 1995 beginning approximately 1900 UT, the GPS Master Control Station began adding data to the spare data fields in the broadcast navigation message. ...
    (sci.geo.satellite-nav)
Loading