On 2021-06-09, ProGeek <progee...@gmail.com> 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.

Sorry but that is nuts. 
Your external sources are 500ms ( 1/2 sec) off from the internal ones.
But that is probably because you told your system to screw up the
internal sources.

>
> 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

Why that offset? and why precision of 1e-1? 
>
> # 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

Why that offset?
Also, why are you having both gpsd and pps0 delivering data? It is the
same pps. And they fight each other-- when one interrupt is processing,
the other one is locked out. This makes the accuracy of pps  less than
it should be (by a factor of about 10)
Tell gpsd not to use the PPS. 

>
> # 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

Why that delay?

HOw about getting rid of all of the offset and delay stuff on your
internal sources. 
>
> something is off but i can't pinpoint what

Sure is. 

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to