On 2021-06-09, chris <chris-nos...@tridac.net> wrote: > On 06/09/21 22:00, ProGeek wrote: >> On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote: >>> On 06/08/21 20:42, Andreas Mattheiss wrote: >>>> Hello, >>>> >>>> just as additional source of information: I have a similar setup here >>>> (ublox PPS into a proper serial port of a PC) and I see a stable offset of >>>> -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd >>>> though. >>>> >>>> Regards >>>> Andreas >>>> >>> This is what I see at the ntp host here: >>> >>> chris@ntp-host:~ % ntpq -pn >>> remote refid st t when poll reach delay offset jitter >>> ====================================================================== >>> o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001 >>> +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054 >>> *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046 >>> >>> Using mini pc host with two network interfaces, internet and internal >>> network facing. FreeBSD 12 with ttl pps into the serial port dcd line >>> via a ttl to rs232 converter... >>> >>> Chris >> this is what i see on sourcestats: >> >> 210 Number of sources = 7 >> .- Number of sample points in measurement set. >> / .- Number of residual runs with same sign. >> | / .- Length of measurement set (time). >> | | / .- Est. clock freq error (ppm). >> | | | / .- Est. error in freq. >> | | | | / .- Est. >> offset. >> | | | | | | On the -. >> | | | | | | samples. >> \ >> | | | | | | >> | >> Name/IP Address NP NR Span Frequency Freq Skew Offset Std >> Dev >> ============================================================================== >> GPS0 12 6 176 -29.089 42.914 -8857us >> 1790us >> SHM1 12 7 178 +0.000 0.010 -530ms >> 435ns >> PPS0 12 7 178 +0.001 0.011 +3ns >> 445ns >> blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms >> 4000ms >> 188.213.49.35 9 6 184 -0.748 21.608 +492ms >> 721us >> time.cloudflare.com 6 4 81 +1.162 9.574 +500ms >> 72us >> time.cloudflare.com 14 11 168 +0.502 0.939 +500ms >> 42us >> >> if i get the results from PPS0 the offset is low, but is still reported >> high. and also correspond with the external time servers. >> >> my settings are like this: >> >> # SHM(0), gpsd: NMEA data from shared memory provided by gpsd >> refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646 >> >> # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd >> refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect >> offset 0.5300 >> >> # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds >> refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust >> prefer delay 0.50 >> >> something is off but i can't pinpoint what > > Just using a standard ntpd here, as it's more than adequate for the > task, with minimum granularity in microseconds. Does look like there > is something seriously wrong, as the gps is 8mS out, and should be > fractions of a mS if working right.
No, it should not be. GPS is the NMEA sentences from the gps device. It is usually delayed by from .1 to .3 sec. Ie, it keeps terrible time. It is the PPS that is spot on to the ns level. > > What I would try is to strip out all except the pps and gps sources > and see what the offset looks like. Also, please post the ntpd.conf He did post the sentences from the chrony.conf file ( the equivalent to the ntpd.conf file) and they are weird. > file, as that can skew everything if misconfigured. Finally, check > the polarity of the pps signal, as the ~500mS offset for several > sources, (0.5 x 1sec), suggest pps input needs an inversion, but the > ntp.conf file has a line to define that... It may be that he has chosen the wrong polarity, but I suspect he has simply chosen the wrong options (the delay and offset options). > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
