Actually, there is a stratum 2 server, based on Debian linux + ntpd. Next, a GPS / Glonass receiver was purchased and an attempt was made to link all this to become stratum 1. And then I did not understand a little 1 moment. Here is the output of the ntpq -p command:
remote refid st t when poll reach delay offset jitter ============================================================================== GPS_NMEA(1) .GPS. 0 l 6 16 17 0.000 41.663 4.561 *ntp1.vniiftri.r .MRS. 1 u 2 64 3 34.693 0.037 1.137 ntp2.vniiftri.r .MRS. 1 u 1 64 3 33.675 -0.033 0.697 n1.ext2-ar.d6.h .PPS. 1 u 1 64 3 43.695 -3.787 0.619 nas3.d6.hsdnnet .PPS. 1 u 56 64 1 50.390 1.075 0.255 GPS clocks lie relative to other stratum 1 servers for 40 ms (on average, when it is less when more), while the delay in receiving data from the same servers is also around 35-40 ms. How is this delay in ntpd taken into account and is it taken into account at all?
At the same time, the /etc/ntp.conf config is present relative to the gps clock relative to the following:
server 127.127.20.1 mode 16 iburst minpoll 4 maxpoll 6 fudge 127.127.20.1 time2 0.84 time2 (delay on transmission along the line) was taken experimentally, but almost constantly this delay floats up and down for about 40 seconds. That is, if you take and put 0.88 there, then at the moment it will help align the time relative to the stratum1 servers, but in an hour it will crawl up or down again.
