[ntp:questions] Time server question

William Unruh unruh at invalid.ca
Fri Jul 19 20:47:15 UTC 2019

On 2019-07-19, Chris <xxx.syseng.yyy at gfsys.co.uk> wrote:
> On 07/18/19 11:13, William Unruh wrote:
>> Sure, but I do not have faith in the "averaging" If one is always 30us
>> after the other, then the average will always be out by 15us.
> One would expect a difference, but how can you tell which one is right
> using just 2 pps ?. With three, you could choose the closest to average
> and discard the outlier, or if it was outside a defined window. Ok,
> it's a bit nitpicking, but would still be interesting to try it.

No. The mechanism is clear. While one is answering its interrupt the
other gets to wait. So, it is the earliest one that is closest to
"right" Ie, do not try to use more than one interrupt on the same
computer. It does not work

>> Writing a special interrupt handler (eg for the parallel port) whose
>> first action is to read the system clock, and it can then allow other
>> interrupts to be handled. That will be good to about 1us. (time to have
>> the interrupt hadler to be loaded into memory, and for it to read the
>> system clock).
> Don't know enough about FreeBSD, but perhaps there is some way to
> specify interrupt priority for a device to minimise latency. It's

There are harddware priorities (parallel port is higher priority to
serial) and there is how much work the computer has to do to anser the
interrupts. (I get the feeling serial is messier than parallel.)

> certainly possible to do that at hardware level, but there's still
> the data pathway uncertainty between the h/w interrupt and the ntp code.
> Signals, shared memory, process priority etc, all introduce uncertainty.
> None of these os's were designed for real time work, but clearly good
> enough for the task...
>> I think the main problem witht he serial port is that it seems to take
>> longer to read that the interrupt has occurred. But I did  my
>> experiments 20 years ago.

More information about the questions mailing list