David Taylor <[email protected]> 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 [email protected] http://lists.ntp.org/listinfo/questions
