On 24/07/2019 08:07, William Unruh wrote:
On 2019-07-24, Jakob Bohm <jb-use...@wisemo.com.invalid> wrote:
On 21/07/2019 16:02, Terje Mathisen wrote:
William Unruh wrote:
...
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
A good timing-optimized gps unit, like the original Oncore, have a sw
mechanism to offset the PPS event away from the actual top of the
second, as well as a way for the sw protocol that numbers the PPS
signals to also specify how far away this particular pulse is from the
actual event.
I.e. with an internal 10 MHz clock, PPS signals will be synced to one of
those 100 ns-wide periods, so it can/will be at least up to +/-50 ns
away from the proper moment, but when the driver knows about this, it
can adjust perfectly for that effect.
Terje
I happen to have a GPS unit (not yet connected) that is documented to do
this too: The PPS pulse occurs at an edge of the internal crystal clock,
but a special NMEA statement states (based on the 4D GPS solution) how
many ns it is off for each pulse. I have yet to find the point to pass
this offset to ntpd after capturing the PPS arrival time.
The problem is this is largely irrelevant. The time it takes the
computer to respond to an interrupt id far far larger (and variable)
than that offset of the pulse which is on the at most 10s of nsec scale.
The computer responds on the usec scale (que the interrupt, the comp
responds to the que and loads or branches to the interrupt service
routine. The routine reads the system clock. All that takes time and a
variable amount of time. Ie, you need specialised hardware to make use
of that information, and, I thought, usually that infomation was
delivered by the gps unit a lond time after the pulse itself. Ie, it is
useful for rewriting history, not for the immediate time.
The hardware under consideration can time the pulse arrivals more
precisely than the interrupt delivery time, thanks to special hardware.
Once that has been set up (in the future), the next problem becomes
applying the higher precision offset to the time source data input to
the ntp algorithms.
At a higher abstraction level this means telling ntp that "at
hhmmss.xxxxxxxxx (local clock), a time stamp of hhmmss.yyyyyyyyy
arrived from this hardware time source".
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
