| Re: [chrony-users] GPS / Chrony NTP server config questions |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Thu, 16 Nov 2017, Rob Janssen wrote:
Bill Unruh wrote:
I am using chrony with serial PPS on a number of different machines, and I
see the 6-7 us figure
on HP Proliant systems while on Dell PowerEdge sytems it is more like 1us.
No idea where the difference comes from.
How do you measure that latency? It does seem that the parallel port is a
much
faster interrupt than the serial port, so it might have something to do
with
the serial port hardware used. (in particular if the serial port is really
a
phony serial->usb port I would expect large latency).
Well, I did not really measure the absolute latency very accurately, it is
more the jitter in the latency what
is appearing in my measurements.
OK. That is of course a different though related question.
I compared two computers each running on a separate GPSDO but close together,
using a scope,
and they were quite close in timing. But those were both Dell computers.
Later we started using HP and the
results were a little worse.
However, my goal for this application is <10us between systems and it is
always possible to achieve that.
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.
RS232 linedrivers with their associated
filtering (slew rate limiting) as defined in the RS232 standard. Equipment
manufacturers may add additional
filters on each line for EMI reasons. The (emulated) 16550 may add other
delays.
A parallel port traditionally was only some 74LS latch, and its current
implementation probably still is faster than a UART.
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.
--
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.