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.

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. :-)

Take care,

Bill