Re: [ntp:questions] NTPQ -P shows both IP and DNS name (parsing problem)
On 20/06/17 14:55, roman.mescherya...@gmail.com wrote: -193.11.114.43 (tor1.mdfnet.se) See the line starting with “-193.11.114.43 (tor1.mdfnet.se)” This strange peer breaks extracting fields by index. For the above example it extracts “(“ as “refid” value instead of “75.17.28.47” and “29.118” as “offset” value instead of “-0.185”. I think you are expected to use the relevant management request directly, rather than parse output intended for humans. That would avoid process startup, filtering, and DNS costs. Is this behaviour a bug or a feature? " Whilst I haven't looked at the code, I wonder if tor is Totally Off the Record", in which case it is quite likely it doesn't reverse resolve correctly. My guess is that it is displaying the information in this form because the reverse resolved name doesn't match the one used, and therefore indicates a possible security issue. In this case, it looks like it reverse resolves to a non-existent domain name. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NTPQ -P shows both IP and DNS name (parsing problem)
Hello everyone, The software developed by me uses ntpq -p to periodically (every 10 seconds) check ntpd time syncing status. ntpq output is parsed and fields “peer”, “refid” and “offset” are extracted by index. This works fine until some strange peer appears in the list for which both IP and DNS name are returned: remote refid st t when poll reach delay offset jitter == 0.debian.pool.n .POOL. 16 p-800.0000.000 0.002 1.debian.pool.n .POOL. 16 p-800.0000.000 0.002 2.debian.pool.n .POOL. 16 p-800.0000.000 0.002 3.debian.pool.n .POOL. 16 p-800.0000.000 0.002 LOCAL(0).LOCL. 10 l 328 100.0000.000 0.002 *193.11.114.43 ( 75.17.28.47 2 u887 29.118 -0.185 2.276 5.20.0.20 193.219.61.110 2 u787 82.7140.315 0.717 -Time100.Stupi.S .PPS.1 u887 29.916 -2.316 2.894 +ntp2.ivlan.net 194.190.168.12 u8875.426 -0.772 2.666 +ntp1.ivlan.net 194.190.168.12 u8878.8400.888 1.217 bagnikita.com 89.109.251.242 u1877.504 -1.115 1.227 78.140.251.2194.190.168.12 u187 14.4410.937 1.559 mx2.volgaship.c 131.188.3.2232 u 1083 13.515 -0.317 0.939 See the line starting with “*193.11.114.43 (“ If I run “ntpq -pw”, then the output is the following: remote refid st t when poll reach delay offset jitter == 0.debian.pool.ntp.org .POOL. 16 p-800.0000.000 0.002 1.debian.pool.ntp.org .POOL. 16 p-800.0000.000 0.002 2.debian.pool.ntp.org .POOL. 16 p-800.0000.000 0.002 3.debian.pool.ntp.org .POOL. 16 p-800.0000.000 0.002 LOCAL(0).LOCL. 10 l 588 2000.0000.000 0.002 -193.11.114.43 (tor1.mdfnet.se) 75.17.28.47 2 u48 77 32.7371.864 0.675 -5.20.0.20 193.219.61.110 2 u38 77 84.743 -0.631 0.543 *Time100.Stupi.SE .PPS.1 u48 77 30.9451.135 1.137 +ntp2.ivlan.net 194.190.168.12 u48 779.2371.225 0.860 +ntp1.ivlan.net 194.190.168.12 u48 779.0851.165 1.026 -bagnikita.com 89.109.251.242 u78 377.879 -0.385 0.591 +78.140.251.2194.190.168.12 u78 37 14.3240.418 1.500 -mx2.volgaship.com 131.188.3.2232 u68 37 13.515 -0.317 1.479 See the line starting with “-193.11.114.43 (tor1.mdfnet.se)” This strange peer breaks extracting fields by index. For the above example it extracts “(“ as “refid” value instead of “75.17.28.47” and “29.118” as “offset” value instead of “-0.185”. ntpq version is 4.2.8p10@1.3728-o Mon May 8 10:30:41 UTC 2017 (1) Is this behaviour a bug or a feature? Kind regards, Roman Mescheryakov ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS-PPS, standalone server. NTP
On Wednesday, June 14, 2017 at 5:37:04 AM UTC+10, David Lord wrote: > Fida Hasan wrote: > > On Thursday, June 8, 2017 at 6:37:04 AM UTC+10, David Lord wrote: > >> : > >>> Le mardi 6 juin 2017 15:28:27 UTC+2, David Taylor a écrit : > On 06/06/2017 13:11, wrote: > [] > > Some GPS will continue to deliver a PPS signal even if the lock is > > lost. I'm thinking particularly about the Garmin 18xLVC where it is > > clearly indicated in the documentation (4.4.1): 'After the initial > > position fix has been calculated, the PPS signal is generated and > > continues until the unit is powered down.' > > > > With the use of that 'kind of' GPS, ntpd will continue to provide time > > service. > As I understand it, NTP will only continue to provide a service if it > has other "time-of-day" sources available. Should the NMEA output (as > the only time-of-day source) become invalid, NTP would reject it, and > gradually ramp itself up to stratum-16 so as to become invalid as a > server to its clients. > > [1 - I'm unsure off the top of my head what NTP checks to know whether > NMEA is valid or not. > 2 - I wonder what the drift in the GPS 18x LVC is when unlocked?] > > -- > Cheers, > David > Web: http://www.satsignal.eu > >>> At least on my 'Garmin', when a fix is not valid the position is not > >>> given but the time message remain available. The GPS internal clock > >>> continue to work. > >>> > >>> One question is to know how stable and precise can be the internal clock > >>> of a 18xLVC GPS model? I don't have yet the answer but if it's comparable > >>> with the one in a Raspberry or Odroid chip then I'm an happy man for some > >>> hours:) > >> Hi > >> > >> NMEA from my 18xLVC was +/- 300ms so I used fudge stratum so that > >> it didn't affect time accuracy if PPS wasn't available. Sometimes > >> there was an inversion layer preventing good GPS reception. The > >> LVC was swapped out to be replaced by a SURE which was still > >> reliable when the PC went down in March this year an has not yet > >> been replaced. > >> > >> from my ntp.conf: > >> server 127.127.20.2 mode 18 prefer > >> fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb > >> server 127.127.22.2 minpoll 4 maxpoll 4 > >> fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb > >> > >> > >> David > > > > Hi David, > > I was just wondering to know the accuracy you have achieved through driver > > 20? Did it turned down to 1-miro or around it? > > > > Regards, > > Fida > > Hi > > with the two gps I've tried, driver 20 is only accurate > enough for numbering the second, say +/- 400ms for my LVC > and maybe +/- 100ms for the Sure. > > Combined with driver 22 I had accuracy down to few us, > mostly better than 1us. > > If you have other internet sources use of driver 20 isn't > essential. > > > David Hi David, Combined with 22, in 20 I have also got 1 micro offset (maximum 1.60 micro) in kernel mode. But in user mode it is more than 5 micro or above. Cheers! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS-PPS, standalone server. NTP
> That command gives all details: > ntpq -c rv -c pe -c cv -c kern -c as > > associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, > version="ntpd 4.2.8p10@1.3728 Tue May 16 04:35:53 UTC 2017 (1)", > processor="armv7l", system="Linux/3.10.104-KPPS", leap=00, stratum=1, > precision=-24, rootdelay=0.000, rootdisp=1.195, refid=GPS, > reftime=dceaa6d4.0b6f4fcb Tue, Jun 13 2017 20:00:52.044, > clock=dceaa6e1.471ffbf5 Tue, Jun 13 2017 20:01:05.277, peer=46420, tc=5, > mintc=3, offset=-0.94, frequency=2.094, sys_jitter=0.60, > clk_jitter=0.001, clk_wander=0.002 > remote refid st t when poll reach delay offset jitter > == > +192.168.0.111 .GPS.1 s 21 32 3770.630 -0.008 0.009 > +192.168.0.112 .GPS.1 s5 32 3770.4490.058 0.011 > 192.168.0.115 192.168.0.1072 s 24 32 3770.6400.006 0.024 > oGPS_NMEA(0) .GPS.0 l 13 32 3770.0000.000 0.000 > associd=0 status= no events, clk_unspec, > device="NMEA GPS Clock", > timecode="$GPRMC,180104,A,.,_,_.,_,000.0,224.0,130617,001.8,E*__", > poll=21509, noreply=0, badformat=0, baddata=0, fudgetime2=550.000, > stratum=0, refid=GPS, flags=13 > associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern, > pll offset:0 > pll frequency: 2.09364 > maximum error: 0.0075 > estimated error: 0 > kernel status: pll ppsfreq ppstime ppssignal nano > pll time constant: 5 > precision: 1e-06 > frequency tolerance: 500 > pps frequency: 2.09375 > pps stability: 0.00802612 > pps jitter:0.001 > calibration interval 256 > calibration cycles:12684 > jitter exceeded: 26092 > stability exceeded:0 > calibration errors:0 > > ind assid status conf reach auth condition last_event cnt > === > 1 46417 f4fd yes yes ok candidate 15 > 2 46418 f43d yes yes ok candidate 3 > 3 46419 f01d yes yes ok reject 1 > 4 46420 971a yes yes none pps.peersys_peer 1 > > As you can see the result is quite good and stable > Best, > Jean-Michel. Hi Jean-Michel, Splendid work. I was just taking sometimes to complete my experiment with my existing system (Rpi-3, GPS HAT (Uputronics)). You know, my result is not bad if I run the system in kernel mode. I have used driver 20 and in the stand-alone mood, means no other servers were associated, no internet connection at all. In user mode I recorded the maximum offset as 6 microseconds. But in kernel mode I run the system over three days, and the maximum offset comes 1.60 microseconds. From the statistical recorded data, I found the average is 1.03 microseconds. I am very interested in going further. I have in mind to try your suggested system with Odroid. You have tested with OdroidC1+, where OdroidC2 is the latest version of it. So, can you please share some points to clear my understanding because I literally have no experiences working with this particular SBC system. 1. Do I need to use OdriodC1+, or OdriodC2+ would be okay?(as I found Rpi3 and others have differences so all of their setting does not mutually works therefore troubleshooting is difficult.) 2. Did you use Linux/or Android as OS? 3. I believe this Odroid is likea clone of Rpi, means, their GPIO Pin configuration is same. So, the Rpi HAT like uputronics provides should fit with it? You are very resourceful. Thank you very much for all of your valuable sharing. This time, I am trying to build with chrony. I have got some references that chrony does better in regard to offsets. I was just wondering if you have any experiences working with chrony! While trying with chrony I still unable to fix gpsd with it therefore no GPS and PPS output is observed. So, 1. I made the necessary configurations: a) In the boot configuration file (/boot/conf.txt) I stop Linux putting serial console by removing 'console=serial0,115200' b) I load pps-gpio to kernel module (sudo sh -c "echo pps-gpio >> /etc/modules" c) Told to use GPIO18 as the PPS input by inputting "dtoverlay=pps-gpio,gpiopin=18" into config.txt file. d) I added this three additional command to the config.txt file, "core_frequency=300" "force_turbo=1" and "enable_uart=1". 2. I installed 'picocom' and 'pps-tools' to see whether my GPS and PPS are from the receiver is functioning? a) 'picocom -b 9600 -f n /dev/ttyS0' commands start to show output from GPS module that essentially starts with $GPRMC b) 'ppstest /dev/pps0' command also executes successfully showing, 'ok found 1 sources (s) bla bla -means, both GPS and PPS of the receiver are interfaced and active with the system. >From this point onward, if I set up
