Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source
On 21/12/2012 19:51, Rick Jones wrote: [] Does the gpsd do anything every 5/3 minutes? Or put another way, can you find a similar periodicity in the CPU utilization? If it does do something interesting at that frequency and it involves a system call, while the act of tracing would perturb things, you might find it in a (timestamped) system call trace (strace) of the gpsd. Perhaps the luck of process scheduling and the gpsd or some other daemon holds-off the ntpd? (Raspberry Pi's are single-core systems right?) Does the ntpd run at a higher (realtime?) priority than the gpsd? Might there be any other background dameons consuming more CPU on the one system than the other? rick jones Thanks for your input, Rick. There's nothing obvious on the CPU plot which correlates with the NTP offset plot, so I'm unsure whether they are related. As an experiment, I've now removed NTP's dependency on gpsd (although it didn't appear to be selected as a source, and was /not/ the prefer source), and I will see whether the oscillation re-occurs. If I still see the problem, I will restart the system without gpsd enabled. The systems are nominally identical, except that the oscillating system has the serial data fed via GPIO pins, and the stable system is using USB for the serial I/O, but that serial data isn't being used anywhere (NTP relies on the LAN servers for its coarse time, and experimentally it's now doing that on /both/ systems). -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source
I have two Raspberry Pi card computers both synced to GPS/PPS sources. #1 is using a u-blox 6M navigation GPS, and #2 a Trimble resolution SMT timing GPS. Every now and then (perhaps one day on ten?), the navigation synced device develops spikes in the offset of about 8 microseconds in duration, as shown here: Graphs for December 20: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#oscillations Current data: http://www.satsignal.eu/mrtg/performance_ntp-pn.php Although the offset appears to have a 1.25 hour period from the MRTG graphs, examining the loopstats directly shows that the actual period is just over about 5/3 minutes - just over 100 seconds. I don't know what's happening. I would have put it down to poor GPS strength, except that the effect lasts almost a whole day, and GPS missing usually contributes bigger offset spikes. I would not expect it to be the navigation mode of the GPS as the excursions are larger than I would expect between navigation and timing modes, but I don't have a lot of experience in that area. One difference in the configuration is that #1 - the one with the offsets - runs and uses gpsd for the coarse seconds, whereas #2 relies on the rest of the network. This seems to causes a higher CPU usage in #1, shown in there graphs: http://www.satsignal.eu/mrtg/performance_raspi-1.php http://www.satsignal.eu/mrtg/performance_raspi-2.php Your comments welcomed! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Although the offset appears to have a 1.25 hour period from the MRTG graphs, examining the loopstats directly shows that the actual period is just over about 5/3 minutes - just over 100 seconds. I don't know what's happening. I would have put it down to poor GPS strength, except that the effect lasts almost a whole day, and GPS missing usually contributes bigger offset spikes. I would not expect it to be the navigation mode of the GPS as the excursions are larger than I would expect between navigation and timing modes, but I don't have a lot of experience in that area. One difference in the configuration is that #1 - the one with the offsets - runs and uses gpsd for the coarse seconds, whereas #2 relies on the rest of the network. This seems to causes a higher CPU usage in #1, shown in there graphs: http://www.satsignal.eu/mrtg/performance_raspi-1.php http://www.satsignal.eu/mrtg/performance_raspi-2.php Does the gpsd do anything every 5/3 minutes? Or put another way, can you find a similar periodicity in the CPU utilization? If it does do something interesting at that frequency and it involves a system call, while the act of tracing would perturb things, you might find it in a (timestamped) system call trace (strace) of the gpsd. Perhaps the luck of process scheduling and the gpsd or some other daemon holds-off the ntpd? (Raspberry Pi's are single-core systems right?) Does the ntpd run at a higher (realtime?) priority than the gpsd? Might there be any other background dameons consuming more CPU on the one system than the other? rick jones -- It is not a question of half full or empty - the glass has a leak. The real question is Can it be patched? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source
On 12/21/2012 11:51, Rick Jones wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Although the offset appears to have a 1.25 hour period from the MRTG graphs, examining the loopstats directly shows that the actual period is just over about 5/3 minutes - just over 100 seconds. I don't know what's happening. I would have put it down to poor GPS strength, except that the effect lasts almost a whole day, and GPS missing usually contributes bigger offset spikes. I would not expect it to be the navigation mode of the GPS as the excursions are larger than I would expect between navigation and timing modes, but I don't have a lot of experience in that area. One difference in the configuration is that #1 - the one with the offsets - runs and uses gpsd for the coarse seconds, whereas #2 relies on the rest of the network. This seems to causes a higher CPU usage in #1, shown in there graphs: http://www.satsignal.eu/mrtg/performance_raspi-1.php http://www.satsignal.eu/mrtg/performance_raspi-2.php Does the gpsd do anything every 5/3 minutes? Or put another way, can you find a similar periodicity in the CPU utilization? If it does do something interesting at that frequency and it involves a system call, while the act of tracing would perturb things, you might find it in a (timestamped) system call trace (strace) of the gpsd. Perhaps the luck of process scheduling and the gpsd or some other daemon holds-off the ntpd? (Raspberry Pi's are single-core systems right?) Does the ntpd run at a higher (realtime?) priority than the gpsd? Might there be any other background dameons consuming more CPU on the one system than the other? I see something similar under NetBSD and a GlobalSat receiver using gpsd for coarse numbering and direct PPS via DCD into ntpd for the PPS sync (ATOM driver). The period of instability in my case is much longer but regular at something like 100 hours (there's also a smaller spike every 24 hours due to logrotate and similar housekeeping). I've never tracked down the 100 hour cycle, though. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source
-Original Message- From: questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org [mailto:questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of A C Sent: Friday, December 21, 2012 3:56 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source On 12/21/2012 11:51, Rick Jones wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Although the offset appears to have a 1.25 hour period from the MRTG graphs, examining the loopstats directly shows that the actual period is just over about 5/3 minutes - just over 100 seconds. I don't know what's happening. I would have put it down to poor GPS strength, except that the effect lasts almost a whole day, and GPS missing usually contributes bigger offset spikes. I would not expect it to be the navigation mode of the GPS as the excursions are larger than I would expect between navigation and timing modes, but I don't have a lot of experience in that area. One difference in the configuration is that #1 - the one with the offsets - runs and uses gpsd for the coarse seconds, whereas #2 relies on the rest of the network. This seems to causes a higher CPU usage in #1, shown in there graphs: http://www.satsignal.eu/mrtg/performance_raspi-1.php http://www.satsignal.eu/mrtg/performance_raspi-2.php Does the gpsd do anything every 5/3 minutes? Or put another way, can you find a similar periodicity in the CPU utilization? If it does do something interesting at that frequency and it involves a system call, while the act of tracing would perturb things, you might find it in a (timestamped) system call trace (strace) of the gpsd. Perhaps the luck of process scheduling and the gpsd or some other daemon holds-off the ntpd? (Raspberry Pi's are single-core systems right?) Does the ntpd run at a higher (realtime?) priority than the gpsd? Might there be any other background dameons consuming more CPU on the one system than the other? I see something similar under NetBSD and a GlobalSat receiver using gpsd for coarse numbering and direct PPS via DCD into ntpd for the PPS sync (ATOM driver). The period of instability in my case is much longer but regular at something like 100 hours (there's also a smaller spike every 24 hours due to logrotate and similar housekeeping). I've never tracked down the 100 hour cycle, though. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions [Mischanko, Edward T] Why use GPSD? I am running FreeBSD 8.2 and use the NMEA driver along with the ATOM driver. If this is incorrect, how do I use GPSD? I am very new to FreeBSD and UNIX in general, so your patience is appreciated. Regards, Ed ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source
On 12/21/2012 19:38, Mischanko, Edward T wrote: -Original Message- From: questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org [mailto:questions- bounces+edward.mischanko=arcelormittal@lists.ntp.org] On Behalf Of A C Sent: Friday, December 21, 2012 3:56 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source On 12/21/2012 11:51, Rick Jones wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Although the offset appears to have a 1.25 hour period from the MRTG graphs, examining the loopstats directly shows that the actual period is just over about 5/3 minutes - just over 100 seconds. I don't know what's happening. I would have put it down to poor GPS strength, except that the effect lasts almost a whole day, and GPS missing usually contributes bigger offset spikes. I would not expect it to be the navigation mode of the GPS as the excursions are larger than I would expect between navigation and timing modes, but I don't have a lot of experience in that area. One difference in the configuration is that #1 - the one with the offsets - runs and uses gpsd for the coarse seconds, whereas #2 relies on the rest of the network. This seems to causes a higher CPU usage in #1, shown in there graphs: http://www.satsignal.eu/mrtg/performance_raspi-1.php http://www.satsignal.eu/mrtg/performance_raspi-2.php Does the gpsd do anything every 5/3 minutes? Or put another way, can you find a similar periodicity in the CPU utilization? If it does do something interesting at that frequency and it involves a system call, while the act of tracing would perturb things, you might find it in a (timestamped) system call trace (strace) of the gpsd. Perhaps the luck of process scheduling and the gpsd or some other daemon holds-off the ntpd? (Raspberry Pi's are single-core systems right?) Does the ntpd run at a higher (realtime?) priority than the gpsd? Might there be any other background dameons consuming more CPU on the one system than the other? I see something similar under NetBSD and a GlobalSat receiver using gpsd for coarse numbering and direct PPS via DCD into ntpd for the PPS sync (ATOM driver). The period of instability in my case is much longer but regular at something like 100 hours (there's also a smaller spike every 24 hours due to logrotate and similar housekeeping). I've never tracked down the 100 hour cycle, though. Why use GPSD? I am running FreeBSD 8.2 and use the NMEA driver along with the ATOM driver. If this is incorrect, how do I use GPSD? I am very new to FreeBSD and UNIX in general, so your patience is appreciated. I'm choosing to use gpsd because my receiver is configured to emit SiRF data instead of NMEA. I'm also using the SiRF data for other functions and gpsd will export the data across network connections. Using the NMEA driver isn't incorrect. It's perfectly acceptable if you're only using the GPS receiver for ntpd. Since I'm using it for other things, I need gpsd's ability to supply data to multiple clients (ntpd is the client by shared memory, other programs are clients by socket connections) and I want some of the SiRF data. Of course ntpd doesn't support SiRF in the first place. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
