Re: [ntp:questions] 1s offset
On 06/03/2013 20:22, unruh wrote: [] 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). [] Yes, it /should/ be the same second, but it depends on how NTP may, or may not, round the value 0.6, for example. I haven't looked at the code to check the actual behaviour. The problem of going into the next second, requiring a fudge of over 1 second, did occur with one lot of Garmin firmware, but was fixed. Yes, it was whether the beginning or end of the sentence was used that made me wonder about the different behaviour of different NTP versions. I recall that in the Windows version it is the end of the first sentence received which has the PPS timestamp substituted as the time of reception. I am less familiar with the UNIX versions. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 1s offset
On 2013-03-07, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 06/03/2013 20:22, unruh wrote: [] 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). [] Yes, it /should/ be the same second, but it depends on how NTP may, or may not, round the value 0.6, for example. I haven't looked at the code to check the actual behaviour. It does not round the time value. It uses it all ( to themicrosecond). The problem of going into the next second, requiring a fudge of over 1 second, did occur with one lot of Garmin firmware, but was fixed. 18x. Yes, it was whether the beginning or end of the sentence was used that made me wonder about the different behaviour of different NTP versions. I recall that in the Windows version it is the end of the first sentence received which has the PPS timestamp substituted as the time of reception. I am less familiar with the UNIX versions. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 1s offset
On 07/03/2013 17:36, unruh wrote: [] Yes, it /should/ be the same second, but it depends on how NTP may, or may not, round the value 0.6, for example. I haven't looked at the code to check the actual behaviour. It does not round the time value. It uses it all ( to themicrosecond). If converting a seconds+fraction number to seconds, it must either round or truncate. It's converting a 64-bit number to a 32-bit one, effectively, when determining the nearest second. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 1s offset
On 05/03/2013 20:32, folkert wrote: Hi, Something odd is happening. I have an old Garmin 18x LVC, a couple of years old and one I bought a couple of weeks ago. The one from a couple of weeks ago has the most recent firmware. The older one only returns one sentence (GPMRC if I remember correctly), the new one has factory default settings and returns a couple of them. Now when I run either 4.2.6p5 or dev-4.2.7p359, I always get an offset of ~1s. Both systems are configured to use NMEA + PPS synchronization. If I use 4.2.5p158 instead, the synchronization is perfect, on both systems. As the older garmin has much older firmware and the new garmin the most recent one (3.80 iirc), I don't think it is firmware issue. Also I tried the new garmin with only 1 nmea sentence but that didn't help. The 4.2.5p158 ntp version does not seem to do ipv6? So that is..., a bit unfortunate. Any ideas? Folkert van Heusden Folkert, 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: (a) 4.2.5p158 looks for the start of the data, not the end and: (b) you haven't specified the appropriate time offset value (fudge field) for the serial data for the other two versions of NTP? Just my initial thoughts. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 1s offset
[ 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: 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: remote refid st t when poll reach delay offset jitter == o127.127.20.0.GPS.0 l5 16 3770.000 -0.060 0.006 -194.109.22.18 193.67.79.2022 u 30 64 177 19.359 -1.282 7.608 -194.109.20.18 193.67.79.2022 u 30 64 177 19.332 -3.155 8.272 +193.67.79.202 .PPS.1 u 28 64 177 21.7720.081 1.864 +192.87.106.2194.171.167.130 2 u 31 64 177 19.7540.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 1760.113 -0.025 0.273 +192.168.62.129 192.168.64.100 2 u 20 64 1770.7130.110 0.534 224.0.1.1 .MCST. 16 u- 6400.0000.000 0.000 192.168.64.255 .BCST. 16 u- 6400.0000.000 0.000 172.29.0.255.BCST. 16 u- 6400.0000.000 0.000 172.19.255.255 .BCST. 16 u- 6400.0000.000 0.000 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 3770.000 -0.089 0.096 -192.168.64.1.GPS.1 u 13 64 1770.135 -0.016 0.185 192.168.62.129 192.168.64.100 2 u 45 64 3760.8510.374 1.573 x82.95.142.92129.70.132.363 u 53 64 377 38.416 -93.971 4.179 127.127.28.0.SHM0. 2 l- 6400.0000.000 0.000 -194.109.22.18 193.67.79.2022 u 35 64 377 19.307 -1.104 2.741 -194.109.20.18 193.67.79.2022 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.2022 u 51 64 377 20.858 -0.886 7.888 Folkert van Heusden -- Feeling generous? - http://www.vanheusden.com/wishlist.php -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 1s offset
On 2013-03-06, folkert folk...@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 l5 16 3770.000 -0.060 0.006 -194.109.22.18 193.67.79.2022 u 30 64 177 19.359 -1.282 7.608 -194.109.20.18 193.67.79.2022 u 30 64 177 19.332 -3.155 8.272 +193.67.79.202 .PPS.1 u 28 64 177 21.7720.081 1.864 +192.87.106.2194.171.167.130 2 u 31 64 177 19.7540.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 1760.113 -0.025 0.273 +192.168.62.129 192.168.64.100 2 u 20 64 1770.7130.110 0.534 224.0.1.1 .MCST. 16 u- 6400.0000.000 0.000 192.168.64.255 .BCST. 16 u- 6400.0000.000 0.000 172.29.0.255.BCST. 16 u- 6400.0000.000 0.000 172.19.255.255 .BCST. 16 u- 6400.0000.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 3770.000 -0.089 0.096 -192.168.64.1.GPS.1 u 13 64 1770.135 -0.016 0.185 192.168.62.129 192.168.64.100 2 u 45 64 3760.8510.374 1.573 x82.95.142.92129.70.132.363 u 53 64 377 38.416 -93.971 4.179 127.127.28.0.SHM0. 2 l- 6400.0000.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.2022 u 35 64 377 19.307 -1.104 2.741 -194.109.20.18 193.67.79.2022 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.2022 u 51 64 377 20.858 -0.886 7.888 Folkert van Heusden ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
