Re: [ntp:questions] ntpd - gpsd communication
On 6/4/20 9:15 PM, a...@avtodoria.ru wrote: > Hello!! > > I have time jumps made by ntpd because gpsd sometimes puts wrong data to SHM > because of wrong data from gps receiver(very bad chips) > > I have only one time source in ntp.conf — 127.127.28.1 with PPS enabled > > I want to add another two internet sources for stability but at first i want > to emulate wrong data from gpsd to see how ntpd will make this time jump. > > As first step i read data from SHM when gpsd worked correctly at 14 p.m. > today UTC+3 for 30 minutes > > And after that i stopped gpsd and launched my own binary at 17:30 p.m. UTC+3 > writing that old data to SHM. I expected the great offset and the time jump > after some time(as it was when receiver lied) but what i saw was: > - without binary launched ntpd had no updates — it’s correct (no data — no > action) > - with binary launched ntpd had a little offset for all 30 minutes without > any attempt to correct system time > > please give me some help!! Maybe i don’t understand ntpd — gpsd communication > correctly or smth else > > Thank you in advance > There's another way to communicate between gpsd and ntpd, using driver 46 (gpsd-json). It probably won't help with a really bad receiver, but it is a bit more sophisticated than the SHM memory slot, even if I say so myself. Stale data is much less of a problem with this driver. It might give different/better results, but I won't make promises here. Cheers, Pearly ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Configuring ntpd to use multiple NTP servers with authentication
Hi all, I’m trying to setup a system which connects to multiple NTP server with symmetric key authentication. For testing, I’m creating my own NTP servers and client taking help from this link. https://access.redhat.com/solutions/393663 I’m using SHA1 as the type of authentication. While I was able to connect to each NTP server, but when tried adding all of them in the ntp.conf file, it is connecting to only one of them, rest of them it is not at all connecting. Looking at the “ntpq -c as” output, it shows auth as “bad” for the server which it is not able to connect. But I was able to connect to the same server in a single server setting. ind assid status conf reach auth condition last_event cnt === 1 49718 f65a yes yes ok sys.peersys_peer 5 2 49719 c01c yesno badreject 1 3 49720 c01c yesno badreject 1 4 49721 903a yes yes nonerejectsys_peer 3 Also, looking at the “ntpq -p” output, I see that the refid is stuck at .INIT. remote refid st t when poll reach delay offset jitter == server1 216.239.35.4 2 u 55 64 3770.560 78.660 1.358 *server2.INIT. 16 u- 51200.0000.000 0.000 server3.INIT. 16 u- 51200.0000.000 0.000 127.127.1.0 .LOCL. 11 l 57 64 3770.0000.000 0.000 ntpstat output: synchronised to NTP server (server1) at stratum 3 time correct to within 123 ms polling server every 64 s content of ntp.conf: # # DO NOT EDIT THIS FILE - it is machine generated # # /etc/ntp.conf, configuration for ntpd # Interface IP addresses to listen interface listen xx.xx.xx.xx # Drift file driftfile /var/lib/ntp/drift # Enable authentication enable auth # Restrictions disable monitor restrict -4 default nomodify nopeer noquery notrap restrict -6 default nomodify nopeer noquery notrap restrict 127.0.0.1 # trust ourself restrict ::1 # trust ourself # Authenticated Server(s) keys /etc/ntp/keys server server1 iburst minpoll 3 key 1 server server2 iburst minpoll 3 key 2 server server3 iburst minpoll 3 key 3 # Specify the key identifiers which are trusted. trustedkey 1 2 3 # Specify the key identifier to use with the ntpq utility. controlkey 1 # Specify the key identifier to use with the ntpdc utility. requestkey 1 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 11 So, my question here is how to configure ntpd to use multiple ntp servers with authentication (SHA-1 only). Thanks, Subhendu. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
Am 05.06.2020 um 09:53 schrieb ah@***.ru: пятница, 5 июня 2020 г., 10:25:24 UTC+3 пользователь Uwe Klein написал: Am 05.06.2020 um 08:36 schrieb ah@***.ru: This sounds more like bit errors in serial reception. ( i.e errors coming up in all magnitudes.) That is reception via NMEA? do you check the NMEA checksum ( Portion after * afair)? Thank you for response. Yes, that is reception via NMEA. No i didn't check checksum, i think gpsd should check it, am i wrong? I just write to log data from SHM when it's all OK. And try to use this correct log after some time to make ntpd change the time. If you think i do something not correct please tell me, i'll try to do something else can you enable data logging and produce logs from the GPS instances that produce errors? ( all sentences received over some time.) Just from a single sytem. As an alternate take a terminal application configured for 4800baud and for the right serial port and log data via that path. never used gpsd put did my own solution years ago for a special use case: https://wiki.tcl-lang.org/page/NTP+plugin+for+a+detachable+nmea+GPS+source ( one app sources NMEA from the device and reflects that into UDP packets.) the other part is sinking UDP packets and funneling those into NTPD. kind of a primitive gpsd replacement ) Uwe I launched gpspipe -R jn all systems, but it's hard to catch it again. I can be not reproducing for a long time Thank you for your decision - did you write it into SHM ? I will see it asaic SHM :: no. it creates an "active" pty device for ntpd to attach to. For ntpd this looks like a regular serial connection. Uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
Am 05.06.2020 um 00:10 schrieb a...@avtodoria.ru: The typical behaviour in case of time jump is that suddenly we have time in gpspipe jumped forth or back for [some seconds - some years]. This sounds more like bit errors in serial reception. ( i.e errors coming up in all magnitudes.) That is reception via NMEA? do you check the NMEA checksum ( Portion after * afair)? Uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
пятница, 5 июня 2020 г., 10:25:24 UTC+3 пользователь Uwe Klein написал: > Am 05.06.2020 um 08:36 schrieb ah@***.ru: > >> This sounds more like bit errors in serial reception. > >> ( i.e errors coming up in all magnitudes.) > > > >> That is reception via NMEA? > >> do you check the NMEA checksum ( Portion after * afair)? > > > > Thank you for response. Yes, that is reception via NMEA. No i didn't check > > checksum, i think gpsd should check it, am i wrong? > > > > I just write to log data from SHM when it's all OK. And try to use this > > correct log after some time to make ntpd change the time. If you think i do > > something not correct please tell me, i'll try to do something else > > > can you enable data logging and produce logs from the GPS instances that > produce errors? ( all sentences received over some time.) > > Just from a single sytem. > > As an alternate take a terminal application configured for 4800baud > and for the right serial port and log data via that path. > > never used gpsd put did my own solution years ago for a special use case: > > https://wiki.tcl-lang.org/page/NTP+plugin+for+a+detachable+nmea+GPS+source > > ( one app sources NMEA from the device and reflects that into UDP packets.) > the other part is sinking UDP packets and funneling those > into NTPD. kind of a primitive gpsd replacement ) > > Uwe I launched gpspipe -R jn all systems, but it's hard to catch it again. I can be not reproducing for a long time Thank you for your decision - did you write it into SHM ? I will see it asaic ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
> What is the wrong data? Ie, how much of an offset does the wrong data > imply? > What does wrong data mean? Do you mean that the PPS is wrong? that of > course has no time attached so can be wrong by only up to 1 second. > Or do you mean that the time reported by the NMEA sentences is wrong? > How wrong? 1 sec? 100 days? We have a lot of computers with different hardware(we can mean it as different generations of equipment). Among this equipment there are different receivers, the last portion of them are stable but the first is not. I have already requested logs with gpspipe -R from system administrators, but we lost those with wrong behaviour and now we are waiting the new event. Try to believe me please... The typical behaviour in case of time jump is that suddenly we have time in gpspipe jumped forth or back for [some seconds - some years]. Ntpd can't believe to that jump but because this source is the only after some time (about 5-10 minutes) ntpd hardly set system time to time in SHM. About 10-15 minutes system time is wrong but ntpd characterisitics are good(offset is less than 1 ms, little jitter etc). We have situation named 'ntpd has been cheated'. After that period of time there is reverse jump in gpspipe -R log. And ntpd again slowly starts to believe in another jump. After all situation becomes OK. > Note that if it really is your GPS that is misbehaving, why not just buy > another board. They are cheap. The Adafruit gps is only about $50. > Your tearing out your hair is probably worth more than that. I agree with you it is the best solution. But managers solved to try to fix it by programmers hands at first. So here am i )) I want to add two another sources to fullfill the complect of three generals)) but at first i want to understand how to cheat ntpd as gpsd regularly does. I think i did all i need. But it looks like i did something wrong in that test. Ntpd eats my data but doesn't touch system time. And i can't understand why ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Observed local difference between public NTP servers and GPS
Hi, I've tried searching with google to try and find an answer to my question, but have failed, so I thought I would try asking here. I've been running ntp for a long time under Linux, relying on ntpd getting time over my DSL connection, and it has done pretty well. The DSL is rather symmetric - currently around 13Mbps down with interleaving and 500kbps up without interleaving, so I suspect the delays on the link are asymetrical (which probably answers my question.) I've had a Mikroe GPS module kicking around doing nothing useful, so today I decided to get it working with ntpd as packaged in Debian Stable (4.2.8p12+dfsg-4). This module contains a ublox LEA6S, and provides both a NMEA output at 9600 baud and a PPS signal. I have configured the LEA6S module to disable all messages except RMC, disabled SBAS (as recommended in the LEA6 documentation) and configured the PPS output to use UTC. All other parameters are as per default (which means an antenna delay of 50ns.) I've built the kernel to use periodic ticks, and included PPS GPIO support. What I've found is that my machine's current idea of time is about 7ms out compared to the GPS - and, as a result, ntpd decides that my new GPS based server is an outlier. sw-dsl: remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l 27 64 3770.000 -0.125 0.004 *mcbin.armlinux. 85.199.214.992 s 58 64 3770.286 -6.771 0.011 +pandora.armlinu 85.199.214.992 s5 64 3770.944 -6.888 0.036 (The GPS offset is slowly decreasing as I write this email as this machine syncs to its new GPS.) pandora: remote refid st t when poll reach delay offset jitter == -ns3.turbodns.co 85.199.214.992 u8 1024 377 31.5130.264 2.001 +gw01-dd.uitserv 10.30.0.29 2 u 51 1024 377 39.2570.573 0.965 +time.netweaver. 85.199.214.982 u 52 1024 377 27.5370.756 0.633 -flint.armlinux. 248.33.116.139 3 u 141 2048 2751.4500.552 0.395 -mcbin.armlinux. 85.199.214.992 u 1931 2048 2561.3120.125 0.201 *server1.quickdr .GPS.1 u 129 64 256 29.4370.851 6.358 +168-84.static.s .UPPS. 1 u 1047 2048 377 37.3211.156 0.541 +ntp2.bucks.net 85.199.214.992 u 903 2048 377 30.9330.796 0.797 +rt0.tfm40.portf 85.199.214.102 2 u 1043 2048 377 31.6090.572 1.171 ntp.mcast.net .MCST. 16 u- 6400.0000.000 0.031 -sw-dsl.armlinux .GPS.1 u 12 64 3770.9426.887 0.033 So, the question is... - should I fudge the new GPS PPS based ntpd to match what I'm getting from the Internet? - should I fudge every explicit server entry that's getting its time off the 'net to bring that into line with my local GPS source? - should I not care? TBH, I don't care about absolute time, I just care about ntpd keeping my machines visibly correct and in sync with each other. However, it seems a waste to try setting up a local GPS and then have everything ignore it. Thanks. -- Russell King ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
Am 05.06.2020 um 08:36 schrieb a...@avtodoria.ru: This sounds more like bit errors in serial reception. ( i.e errors coming up in all magnitudes.) That is reception via NMEA? do you check the NMEA checksum ( Portion after * afair)? Thank you for response. Yes, that is reception via NMEA. No i didn't check checksum, i think gpsd should check it, am i wrong? I just write to log data from SHM when it's all OK. And try to use this correct log after some time to make ntpd change the time. If you think i do something not correct please tell me, i'll try to do something else can you enable data logging and produce logs from the GPS instances that produce errors? ( all sentences received over some time.) Just from a single sytem. As an alternate take a terminal application configured for 4800baud and for the right serial port and log data via that path. never used gpsd put did my own solution years ago for a special use case: https://wiki.tcl-lang.org/page/NTP+plugin+for+a+detachable+nmea+GPS+source ( one app sources NMEA from the device and reflects that into UDP packets.) the other part is sinking UDP packets and funneling those into NTPD. kind of a primitive gpsd replacement ) Uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
пятница, 5 июня 2020 г., 10:04:44 UTC+3 пользователь William Unruh написал: > On 2020-06-05, a...@avtodoria.ru wrote: > >> This sounds more like bit errors in serial reception. > >> ( i.e errors coming up in all magnitudes.) > > > >> That is reception via NMEA? > >> do you check the NMEA checksum ( Portion after * afair)? > > > > Thank you for response. Yes, that is reception via NMEA. No i didn't check > > checksum, i think gpsd should check it, am i wrong? > > > > I just write to log data from SHM when it's all OK. And try to use this > > correct log after some time to make ntpd change the time. If you think i do > > something not correct please tell me, i'll try to do something else > > > > You are tracking the wrong problem. The problem is NOT ntpd. The problem > is the time you are getting from gps/gpsd/shm. That is where you should > be looking, not ntpd. ntd has been used for about 40 years now. It > works. Similarly gpsd. Your boss is telling you to fix something that is > not broken, wasting whatever salary they are paying you. Do they really > have solittle for you to do that is useful? > You have not told us what operating system you are using. Or anything > about your systems, except some are old (3mo?, 3yr? 10 yr? 30 yr?) No-no-no... i didn't tell ntpd or gpsd are wrong.. Sorry, if i said something like that, i have no enough practice in english communication to be confident i make right language constructions :) I agree with you receivers are bad, i agree they receive wrong data or there are some problem in serial port or smth else But. What i want to say is that this wrong situations make ntpd to do some changes to system time. And i want to simulate that situation. That's all. My system is ALT Linux 6.0.0 Centaurus (Cheiron), 4.4.135-std-pae-alt1 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntpd - gpsd communication
Hello!! I have time jumps made by ntpd because gpsd sometimes puts wrong data to SHM because of wrong data from gps receiver(very bad chips) I have only one time source in ntp.conf — 127.127.28.1 with PPS enabled I want to add another two internet sources for stability but at first i want to emulate wrong data from gpsd to see how ntpd will make this time jump. As first step i read data from SHM when gpsd worked correctly at 14 p.m. today UTC+3 for 30 minutes And after that i stopped gpsd and launched my own binary at 17:30 p.m. UTC+3 writing that old data to SHM. I expected the great offset and the time jump after some time(as it was when receiver lied) but what i saw was: - without binary launched ntpd had no updates — it’s correct (no data — no action) - with binary launched ntpd had a little offset for all 30 minutes without any attempt to correct system time please give me some help!! Maybe i don’t understand ntpd — gpsd communication correctly or smth else Thank you in advance ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
> This sounds more like bit errors in serial reception. > ( i.e errors coming up in all magnitudes.) > That is reception via NMEA? > do you check the NMEA checksum ( Portion after * afair)? Thank you for response. Yes, that is reception via NMEA. No i didn't check checksum, i think gpsd should check it, am i wrong? I just write to log data from SHM when it's all OK. And try to use this correct log after some time to make ntpd change the time. If you think i do something not correct please tell me, i'll try to do something else ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd - gpsd communication
On 2020-06-05, a...@avtodoria.ru wrote: >> This sounds more like bit errors in serial reception. >> ( i.e errors coming up in all magnitudes.) > >> That is reception via NMEA? >> do you check the NMEA checksum ( Portion after * afair)? > > Thank you for response. Yes, that is reception via NMEA. No i didn't check > checksum, i think gpsd should check it, am i wrong? > > I just write to log data from SHM when it's all OK. And try to use this > correct log after some time to make ntpd change the time. If you think i do > something not correct please tell me, i'll try to do something else > You are tracking the wrong problem. The problem is NOT ntpd. The problem is the time you are getting from gps/gpsd/shm. That is where you should be looking, not ntpd. ntd has been used for about 40 years now. It works. Similarly gpsd. Your boss is telling you to fix something that is not broken, wasting whatever salary they are paying you. Do they really have solittle for you to do that is useful? You have not told us what operating system you are using. Or anything about your systems, except some are old (3mo?, 3yr? 10 yr? 30 yr?) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
