Looks like you still need a round of calibration - to calculate the value to use to adjust your ‘time1’ parameter for the latency in the connection to your refclock.
Many GPS devices have the same problem of delayed GPS time output, including my Garmin 18x OEM. I am too lazy to calculate the offset of SHM(0), so I disable it and get second data from network then calibrate it by SHM(1) PPS data. Of course this configuration cannot work in isolated network, but should not be a problem for NTP pool servers.
My current ntpq -p output:
remote refid st t when poll reach delay offset jitter
*SHM(1) .PPS. 0 l 33 64 377 0.000 0.000 0.004
-118-163-81-62.H 192.168.0.3 2 u 17 64 377 4.036 1.621 0.361
-211-22-103-157. 192.168.0.3 2 u 58 64 377 4.240 1.612 0.111
-118-163-81-61.H 192.168.0.2 2 u 23 64 377 4.163 1.539 0.164
+211-22-103-158. 192.168.0.2 2 u 56 64 377 4.468 0.947 0.625
-118-163-81-63.H 192.168.0.2 2 u 61 64 377 4.044 1.918 0.385
-223.255.185.2 .192.. 1 u 20 64 357 54.009 -17.774 0.526
+ntp-a3.nict.go. .NICT. 1 u 16 64 257 33.138 0.017 0.161
Hi thanks for the replies. @tychotithonus Am i correct in saying i can use the offset generated by ntpviz? http://time.arihanc.com/week/index.html
looking at the weekly stats for SHM(0) it seems to be median = -0.515241 so id put it as a positive correct?
@alica Thats handy to know thanks, although id like to get the GPS working if i can its not the end of the world just to use PPS.
@arihancc Yep, that looks about right. If you want to be extra precise, you might look at the actual peerstats file data to see if there are any major outliers that should be discarded, create a cleaned up copy of the peerstats, and calculate the average on that clean copy using the awk snippet.