Bill Unruh wrote:
All of those systems have an "onboard UART". Setserial determines them as:
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
However there is of course no 16550A anywhere on those boards, it is a cell in
some system support chip.
It is true that parallel is better than serial, if only due to the lack of
The problem of course is that very few computers come with parallel ports
these days.
The same holds for serial ports. And when there is one, it might well be a
bit-banged port with only Rx/Tx data,
or a USB device. Fortunately we are dealing with "server grade" systems that
usually still have a serial port or two.
For really accurate PPS handling one would want a dedicated PCI-E card with a
clock oscillator and a counter,
latched in a register on PPS edge, and issuing the interrupt. The driver would
then read the latched counter
value and the current counter value on interrupt. The interrupt response time
becomes irrelevant because the
actual timestamp has been latched by the hardware. I think some Meinberg
products use this method.
Certainly, but that is another expense which is really beyond the chrony/ntpd
level. Of course one then has to relate that timestamp on the card to the
computer's system time, and take into account that card counter's changes in
drift etc. Ie, one have two clocks not to discipline-- the onboard counter and
the system clock. Not that that is that difficult but it is an added
complexity.
It depends on the approach. You could have a 10 MHz oscillator disciplined to
GPS and ticking a counter and
discipline that for real time, but a simpler approach is to just have a
freerunning 10 MHz (or so) crystal oscillator
that ticks a counter that you latch at PPS event time and then in the handler
readout the current counter value
and the latched value, subtract them, and you know your interrupt latency for
that particular pulse. You also readout
the system time as usual and discipline it using the PPS, but corrected for the
latency.
When your latency is of the order of 1-10us (say 100us worst case), the effect
of an error in the 10 MHz is very
small because it is scaled by the factor latency/total time, or about 10^5, and
an error there only slightly affects the
accuracy of real time, not the drift of the clock etc.
I have some plans for our system to offload the entire accurate timing thing to
an external board anyway. Just
NTP discipline of the clock will be sufficient, and then the 10 MHz and 1PPS
from the GPSDO go to an external
board that does the exact timing in an FPGA or similar.
Rob
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
