[ntp:questions] 1s offset
unruh
unruh at invalid.ca
Wed Mar 6 20:22:02 UTC 2013
On 2013-03-06, folkert <folkert at vanheusden.com> wrote:
> [ garmin 18x lvc & offsets ]
> ...
>> >Now when I run either 4.2.6p5 or dev-4.2.7p359, I always get an offset
>> >of ~1s.
> ...
>> >If I use 4.2.5p158 instead, the synchronization is perfect, on both
>> >systems.
>
>> Agreed that it's unlikely to be a firmware issue, but there is an
>> interesting graph here:
>> http://www.satsignal.eu/ntp/Garmin-GSP18x-LVC-firmware-issue.htm
>> specifically:
>> http://www.satsignal.eu/ntp/Garmin-18x-3.7.png
>> which shows that the end of the NMEA sentence may be well over 0.5 s
>> after the PPS, and hence into the next second. Could it be that:
That should all be in the same second. The nmea sentence cannot come
before the PPS, so the "one second" should all be between the PPS pulse
and the next one. The problem occurs if the end of the sentence comes
after the next pulse occurs.
The code should probably use the beginning of the sentence, not the end,
to mark the time. It can always throw away the timestamp if it is not
needed. Or at least once it knows that the appropriate sentence is
coming. (the first four or 5 characters received).
>
> True.
>
>> (a) 4.2.5p158 looks for the start of the data, not the end
>
> I should do a bisect. No SVN/GIT repository though?
>
>> and:
>> (b) you haven't specified the appropriate time offset value (fudge
>> field) for the serial data for the other two versions of NTP?
>
> I looked at my changes of yesterday and I saw that I tried, then "time1
> 1.0" which should be "time2 1.0".
> And after 7 minutes it is:
That should not be necessary.
>
> remote refid st t when poll reach delay offset jitter
>==============================================================================
> o127.127.20.0 .GPS. 0 l 5 16 377 0.000 -0.060 0.006
> -194.109.22.18 193.67.79.202 2 u 30 64 177 19.359 -1.282 7.608
> -194.109.20.18 193.67.79.202 2 u 30 64 177 19.332 -3.155 8.272
> +193.67.79.202 .PPS. 1 u 28 64 177 21.772 0.081 1.864
> +192.87.106.2 194.171.167.130 2 u 31 64 177 19.754 0.205 3.468
> +134.221.205.12 .PPS. 1 u 27 64 177 21.460 -0.398 5.835
> +192.168.64.100 .GPS. 1 u 46 64 176 0.113 -0.025 0.273
> +192.168.62.129 192.168.64.100 2 u 20 64 177 0.713 0.110 0.534
> 224.0.1.1 .MCST. 16 u - 64 0 0.000 0.000 0.000
> 192.168.64.255 .BCST. 16 u - 64 0 0.000 0.000 0.000
> 172.29.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.000
> 172.19.255.255 .BCST. 16 u - 64 0 0.000 0.000 0.000
I do not see anything there which is the PPS pulse. (the 192.168.64.100
is another machine).
I did not think tha the GPS included PPS. (and the jitter below is really too
high for PPS.)
>
> This looks promising!
>
> I'll let it run for a night and see what is happing. The other system,
> which still runs 4.2.5p158, gives after half a day:
>
> remote refid st t when poll reach delay offset jitter
>==============================================================================
> *127.127.20.1 .GPS. 0 l 14 16 377 0.000 -0.089 0.096
> -192.168.64.1 .GPS. 1 u 13 64 177 0.135 -0.016 0.185
> 192.168.62.129 192.168.64.100 2 u 45 64 376 0.851 0.374 1.573
> x82.95.142.92 129.70.132.36 3 u 53 64 377 38.416 -93.971 4.179
> 127.127.28.0 .SHM0. 2 l - 64 0 0.000 0.000 0.000
Here is teh shm, and it should be the preferred tinme source, not the
GPS. But it is not working.
> -194.109.22.18 193.67.79.202 2 u 35 64 377 19.307 -1.104 2.741
> -194.109.20.18 193.67.79.202 2 u 21 64 377 19.382 -2.231 3.765
> +193.79.237.14 .PPS. 1 u 60 64 377 20.894 -0.693 4.470
> +192.87.36.4 .GPS. 1 u 10 64 377 23.136 -0.976 4.772
> -134.221.205.12 .PPS. 1 u 62 64 377 22.208 -1.076 3.891
> -172.29.0.11 193.67.79.202 2 u 51 64 377 20.858 -0.886 7.888
>
>
> Folkert van Heusden
>
More information about the questions
mailing list