[ntp:questions] GPS-PPS, standalone server. NTP
unruh at invalid.ca
Thu Jul 6 12:12:16 UTC 2017
On 2017-07-06, Fida Hasan <k.fidahasan at gmail.com> wrote:
>> You mean that the fluctuation in theoffset if 1.6us. YOu have no way of
>> knowing what the actual offset is, or do you have an independent clock?
>> Ie, ntp could be adding 100ms to the time and you would not know it.
>> (Not that that would be likely but 2 or 3 usec could be likely)
> Thanks William! You are right. NTP adjustment and mitigation loops play a role in this part.
> I made a straightforward experiment with two Rpi that are sync with two individual GPS with an offset of 1.6 micro (that what NTP shows) each. In P2P mode I connected them through ethernet cable and gave one's address in other's ntp.conf as a server while the node was sync with PPS-GPS in either circumstance. Primarily I found their offset shows 20 microseconds!
> It is interesting because theoretically, we know that gps is highly accurate in ns level. Due to some hardware jitters, there might have some additional offsets but they should not be larger like that.
> I observed some experiments have been conducted in hardware level through a direct connection with signal measurement instruments like the oscilloscope. Those result shows the offsets between two gps receivers are around 100 ns! So, the receiver I am using right now, I compared them using oscilloscope and found similar offsets (100 ns). But they are as high as 20 micro in my RPi.
The gps delivers a pps pulse to its output with an delay of something
like 10-100 ns. Then the gps raises the PPS line, which is almost
certainly not terminated properly so the pulse has an indetermnate rise
time. Then the gpio triggers an interrupt at some point on that rise and
it takes a while for the computer to page out what it is now doing and
start he interrupt service routine. It then has to read out the time
from the kernel. All of that takes time, time which is not accounted
for. Basically the system says that the pps pulse occured when the clock
is read out, which is of the order of a microsecond after the gps
delivered the pps pulse to its output. To really get say 100ns
precision, you need to compensate for all of those delays. They all have
jitter as well (jitter which only increases the time delay, not
decreases it-- eg the interrupts happen to be masked when the pulse
actually comes in, the computer is busy in an non-interrruptable
routine, etc. Ie to get into the ns regime you have to work hard on all
those delays, and you will not get it from a RPi.
Note that timing gps receivers will have a compensation for internal
delays ( which apparently tend to look like staircases) which it can
tell the computer about well after they have occured. So you can
compensate for them after the fact.
(PS it would be nice if youput line breaks ito your posts).
> So, along with NTP some other jitters are there. Now, my question, wheather it is possible to command NTP to stop adjustment only say to fix the GPS PPS with the system clock. If it is possible then I can understand how accurately Rpi can produce GPS PPS signal!
>> The shm drive is one way. Another is the pps driver
>> Make sure that you have the
>> timepps.h header file somewhere. You have to find it somewhere .
>> If you have it, and you make chrony, it woill be built witht eh PPS API
>> Then before starting chrony and assuming you have the pps fed into the
>> the serial port /dev/ttyS0, do
>> modprobe pps-ldisc
>> ldattach 18 /dev/ttyS0
>> Then in chrony.conf put
>> refclock PPS /dev/pps0
>> and you should be set up.
> I followed your guide and tried with Chrony. Very unfortunately I can not develop Chrony in my system.
> Problems are:
> 1 If I install Chrony from repository (apt-get install chrony), I cant interface it with PPS API, and I even don't find 'chronyd' daemon in my system.
> 2. While trying to install manually (https://chrony.tuxfamily.org/doc/3.1/installation.html), it gives make error!
> Completely stuck!
More information about the questions