lightswitch05
Joined 13 years ago
Joined 13 years ago
Using the same receiver, but with a PPS wire to a GPIO pin on a raspberry pi, I get +/- 5µs jitter.
If you are interested, I have a write up with live graphs in the hamburger menu here: https://www.developerdan.com/ntp
> While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required;
And so (with NTPsec), you need to define two sources even though it’s coming from the same device. One for the PPS signal for clock discipline, the other for the clock value.
> refclock pps ppspath /dev/gpspps0 prefer
> refclock nmea baud 57600 prefer
I’ve messed around with this on a couple different GPS chips. I’ve found improvements can be made by increasing the baud rate to the maximum supported. 9600 tends to be the default, but 57600 works a lot better. Also, disable all NMEA sentences except the one you are using. Finally ramp up the update interval to be much more often. The default tends to be every 1000 milliseconds, but 100 milliseconds works better for less jitter. I’ve been using NTPsec, not Chrony, so maybe there are more nuances.
Im just a hobbyist, but I have a bit more details written up here, checkout the poorly designed hamburger menu for some charts and graphs: https://www.developerdan.com/ntp/
https://shop.raspberryshake.org/product/turnkey-iot-atmosphe...
I'm going to have to check this out! Thank you for sharing!
* Clayface: https://www.developerdan.com/ntp/#./clayface/7-days/
* Catwoman: https://www.developerdan.com/ntp/#./catwoman/7-days/
That Wikipedia quote should mention temperature! Temperature variations have a big impact at this level of accuracy. These really cheap GPS receivers do not have temperature adjusted clocks. Unfortunately my server closet (this is just a hobby) does not have well regulated temperature, so you can see the impact of temperature on the clock accuracy. Also, I found if I start running a bunch of stuff on these computers - that makes the CPU heat up, which also affects the jitter. If you really want high-precision, you'll have to shell out some extra cash then I did: https://www.sparkfun.com/products/18774
refclock pps ppspath /dev/gpspps0 prefer time1 0.004 minpoll 3 maxpoll 4 iburst
refclock nmea baud 57600 time2 0.068 minpoll 3 maxpoll 4 prefer iburst
To get around issues with sync being slow, I have NTPD configured with some extra flags to allow large time jumps at startup: NTPD_OPTS="-ggg -N"
I have two raspberry pies setup this way- which I don’t use for much else. My primary computers have these two servers configured as time sources- but also have external sources- so as long as network connections are available, they can determine if they are providing a sane time or are false tickers. As for accuracy, you can view the ntpviz output for each setup in the hamburger menu. For catwoman, its regularly within 4 microseconds.Shameless promotion time, I have a little utility that can check a node version for CVEs or EOL:
npx node-version-audit@latest --fail-security
Or with docker: docker run --rm -t lightswitch05/node-version-audit:latest --version=$(node -e "console.log(process.versions.node)")
Some highlights of the tool is zero dependencies and CVEs are sourced directly from NPM changelogs instead of waiting on slow CVE release processes. See the website for more details: https://www.github.developerdan.com/node-version-audit/Anyways, after running for three years, I thought it would be fun to put together some data. The most interesting one is that PHP Version Audit has a median CVE discovery of 5 hours after the PHP announcement. In contrast, the NVE CVE Database has a median of 260 hours - or almost 11 days. Of course the NVE CVE Database has all sorts of information like a vulnerability score, so maybe it’s an apples vs. oranges comparison. Anyways, I hope someone else finds this interesting :)
If you think PHP Version Audit is interesting, there is also Node Version Audit[0] that I released earlier this year.