[chrony-users] PPS time

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


I have two sets of questions about chrony, but they're sort
of independent, so I'm going to ask them in separate messages.
This one is about PPS timing, and specifically, about trying to
run a Linux box on what amounts to PPS only.

[If you don't want all the background, skip down to "So my
questions are basically".]

We have a system with a perhaps peculiar set of requirements:
It is not connected to the public internet, and it only
occasionally has GPS reception.  The system includes a
high-accuracy reference clock (either a Brandywine PC104SG card
or a MicroSemi chip-scale atomic clock) to keep good time while
it doesn't have GPS.  The system is powered on only intermittently
(say, for up to 24 hours at a time), and we can assume that it
*does* have GPS reception at power-up.  The most important
requirement is that all clocks within this system (there are
several, one a Linux computer running chrony) be perfectly
synchronized.  It is less important that the system have
millisecond- or microsecond-level synchronization with UTC.
But it is *very* important that, once it is operating, the
system never experience any time jumps or even any significant
adjustments which might leave any of its subsystems desynchronized.

So we have decided that we'd like to synch to GPS exactly once,
at power up, and then *never sync to GPS again*.  After power-up,
all timing in the system is supposed to be driven by the PPS
output of the internal reference clock.

It took us a while to arrive at the "never synch to GPS again"
part of the solution, and it sounds counterintuitive or even
heretical at first.  But if we don't need perfect synchronization
to UTC and can't tolerate adjustments, if we can assume that the
initial GPS time synch is good enough and that the reference
clock's 24-hour accuracy is also good enough, the conclusion
becomes more or less inescapable.

(I can tell you that, before we arrived at this "heretical"
requirement, we have regularly had significant problems.
In our environments, and with the GPS receivers we use, it is not
at all uncommon for the initial GPS synch and a later GPS hit --
separated, that is, by a period of GPS loss -- to somehow differ
enough in accuracy that the later GPS hit wants to initiate a
timing adjustment of one clock or another in the system, an
adjustment which we would find intolerable.  Thus the desire
to ignore GPS after the initial synch.)

So the question, then, is how to set things up to achieve these
requirements.  Stated another way, how do we configure chrony to
listen to GPS initially, but then to ignore it and pay attention
*only* to the PPS signal coming out of our reference clock?
(We do have pretty complete control over both our hardware and our
software, so some aspects of our solution can be and already are
customized.)

This is complicated by the fact that chrony doesn't seem to want
to listen to PPS alone.  As the FAQ list states,

	A pulse-per-second (PPS) reference clock requires a
	non-PPS time source to determine which second of UTC
	corresponds to each pulse.

So my questions are basically, are there any ways around this
limitation, to achieve what we're trying to do?  Specifically:

* Does chrony have anything like ntpd's tos minsane parameter?
  (According to the documentation for ntp's driver22, with
  minsane = 0, "if no sources are available, the system clock
  continues to be disciplined by the PPS driver on an indefinite
  basis".)

* Is there a good way to readjust chrony's time sources on the
  fly, to achieve our desired configuration of "use GPS initially,
  but then after the first synch, don't"?

* If dynamic reconfiguration is a bad idea, is there any way to
  get chrony to just listen to PPS only, to steer the system
  clock to PPS without worrying about what time it is?  (We'd
  be perfectly happy to set the Linux clock once, at power up,
  "by hand", from our code, using date(1) or settimeofday(2).)

* Is there a way to configure chrony to *use the system clock*
  as a source for second-level timing information, using PPS only
  for subsecond steering?  (Yes, I know this sounds terribly
  circular, but is it completely insane?)

* Should I be looking into a way to get second-level as well as
  subsecond timing information out of our reference clock and
  into chrony, so that there's never any ambiguity on this score
  at all?

As a point of departure, the refclock sources we're using in
chrony.conf today (that do not reflect answers to these questions
and do not really meet our requirements) are:

	refclock SHM 0 refid GPS precision 1e-1 filter 1000 noselect
	refclock SHM 1 refid PPS precision 1e-9 trust

Thanks very much if anyone can provide answers to any of these
questions.  (Sorry there have been so many and that this message
has been so long...)

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/