At 10:11 AM -0800 3/25/98, Bill Studenmund wrote:
>On Wed, 18 Mar 1998, Henry B. Hotz wrote:
>
>> Bear with me here.  I have an idea for "fixing" the CPU clock drift problem
>> that may not require any software change.
>>
>> What is the relative priority of the serial ports and the main timer?  I
>> seem to recall someone saying that the main clock was hardwired at the
>> lowest priority level.  Therefore a timing source on a serial port would be
>> more reliable than the main timer.
>
>No, the problem is we're using an interrupt model designed for systems
>with a high-priority clock when we don't have one.
>
>> I see that there is an option PPS_SYNC available in 1.3.
>>
>> Is it possible to set the baud rate of a serial port to 1 (that is 1
>> bit/second)?
>
>It should be, though 10 bits/sec would be better (one character /sec)
>
>> Conclusion:  maybe a proper loopback plug combined with a kernel with both
>> options NTP
>> options PPS_SYNC
>> and a proper NTP and serial port configuration could be taught to keep
>> proper time?
>
>Don't need the loopback plug. The serial port can be set to a loopback
>mode. Something along the lines of a line discipline would work better.
>
>the real problem is that we have a two-level serial driver. The LOWER
>(next to the hardware)  level runs at interrupt level 4 (the highest), but
>the upper level, which deals with line disciplines, runs at about the same
>level as the clock servicer.
>
>If we wanted to go this route, Something closer to 1000 bps would be
>better. We have the line discipline keep the write buffer full, and each
>character it gets represents one tick. The advantage here is that ticks
>don't get lost.

OK, I think a little more explanation of my thinking is in order.

First, NTP is set up to look for 1 PPS (1 pulse/second) inputs already, and
"options PPS_SYNC" is supposed to provide the proper line discipline and
interface it to the NTP kernel process.  Thanks for confirming that 1 (or
10) baud is worth trying.  What I was proposing was an
absolutely-zero-change solution until someone figures out the right thing.

Second, the clock drift problem currently is that the clock interrupt is
both frequent and low-priority.  We can fix, or at least alleviate the
problem by either using a less-frequent interrupt so it doesn't step on
itself before being serviced, or by using a higher-priority interrupt so it
gets serviced before stepping on itself.

Third, I had in mind an NTP configuration with the local clock at stratum
13 or 15 or so, and the serial line signal at stratum 10 or so.  That would
make NTP trust the serial clock more than the lossy regular clock, while
having both much lower than any "real" clock (that might be intermittently
connected).

>Though I think a better idea would be to help Scott re-write our interrupt
>handler so we don't have this problem at all. :-)

No argument.  I'm just not up for it.  I haven't even done any followup to
try my original idea yet.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu