Re: [time-nuts] raspberry pi, adafruit gps ntp
Hello, The last 25 hours I measured the jitter of my RPi-with-userspace PPS processing. In the following graph you'll see those measurements. Each row is an hour: http://vps001.vanheusden.com/~folkert/jitter-hm.png There's some kind of wave in it which I cannot explain: everything not related to timekeeping (apart from sshd) is disabled on that device. No cron, no at, not even the processes that monitor the state of the network port. Allan deviation: http://vps001.vanheusden.com/~folkert/allandev.png Folkert van Heusden -- -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
I've now add Folkert's user-mode method to my NTP/Raspberry Pi notes here: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode Comments and corrections welcomed. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
After 51 minutes of ntpd run-time this gives: remote refid st t when poll reach delay offset jitter == *firewall.intran 192.168.64.2 3 u7 64 3770.560 -0.506 0.493 -belle.intranet. 192.168.64.2 3 u 58 64 3770.560 -0.470 0.405 -time2.intranet. 194.109.20.183 u 56 64 3771.034 -1.282 1.392 +auth1.xs4all.nl 193.67.79.2022 u 28 64 377 17.580 -0.160 0.490 xSHM(0) .NMEA. 0 l1 16 3770.000 -359.47 10.670 +SHM(1) .PPS.0 l18 3770.0002.964 0.061 After 12,5 hours: remote refid st t when poll reach delay offset jitter == *192.168.64.1192.168.64.2 3 u 280 1024 3770.534 -0.924 0.579 -192.168.64.100 192.168.64.2 3 u 451 1024 3770.625 -0.920 0.560 -192.168.62.129 194.109.22.183 u 278 1024 3771.661 -2.347 0.665 +194.109.22.18 193.67.79.2022 u 295 1024 377 17.719 -0.357 0.978 x127.127.28.0.NMEA. 0 l5 16 3770.000 -309.57 40.640 +127.127.28.1.PPS.0 l48 3770.0002.231 0.005 Looking good! It is probably selecting 192.168.64.1 due to an accidental prefer keyword for that server in the configuration. I'm surprised that the jitter goes down to 0.005 as I'm now measuring the PPS from userspace. My program runs with real time scheduling and maximum priority but still the kernel needs to do a context switch etc. when it receives the pps pulse. Folkert van Heusden -- MultiTail er et flexible tool for å kontrolere Logfiles og commandoer. Med filtrer, farger, sammenføringer, forskeliger ansikter etc. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
From: folkert [] I'm surprised that the jitter goes down to 0.005 as I'm now measuring the PPS from userspace. My program runs with real time scheduling and maximum priority but still the kernel needs to do a context switch etc. when it receives the pps pulse. Folkert van Heusden That sounds good, Folkert - perhaps you might publish the details somewhere? I'd like to try it myself, but my Linux and C knowledge is limited. For comparison, on three RPi cards here with modified kernels to get PPS from a GPIO pin, using ntpq -pn I see jitter values of 0.002, 0.002 and 0.002/0.004. The 0.002 seems to be near the sys_jitter limit as reported from ntpq -c rv. Cards 1 and 2 are just doing NTP, the third card is running a data collector processing signals from a DVB receiver stick, and sending the derived data over a Wi-Fi link to a PC running Plane Plotter using the dump1090 program. This gives a CPU load around 35%. It would be interesting to know how your version handles a busy RPi. http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html http://www.satsignal.eu/Radio/dump1090.html http://www.satsignal.eu/mrtg/performance_raspi-3.php Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
Hi David, That sounds good, Folkert - perhaps you might publish the details somewhere? I'd like to try it myself, but my Linux and C knowledge is limited. Here it is: http://vanheusden.com/time/rpi_gpio_ntp/ Please let me know if anything is unclear: I'll then enhance e.g. the readme.txt and such. For comparison, on three RPi cards here with modified kernels to get PPS from a GPIO pin, using ntpq -pn I see jitter values of 0.002, 0.002 and 0.002/0.004. The 0.002 seems to be near the sys_jitter limit as reported from ntpq -c rv. That's indeed better. The results I see are probably also influenced by the fact that this RPI also does other things (software defined radio, camera and measuring the light intensity outside). Cards 1 and 2 are just doing NTP, the third card is running a data collector processing signals from a DVB receiver stick, and sending the derived data over a Wi-Fi link to a PC running Plane Plotter using the dump1090 program. This gives a CPU load around 35%. It would be interesting to know how your version handles a busy RPi. Hmmm, I'll see if I can setup an RPI which only does the time keeping and see if that gives better results. Folkert van Heusden -- MultiTail na wan makriki wrokosani fu tan luku den logfile nanga san den commando spiti puru. Piki puru spesrutu sani, wroko nanga difrenti kroru, tya kon makandra, nanga wan lo moro. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
Hi David, That sounds good, Folkert - perhaps you might publish the details somewhere? I'd like to try it myself, but my Linux and C knowledge is limited. Here it is: http://vanheusden.com/time/rpi_gpio_ntp/ Please let me know if anything is unclear: I'll then enhance e.g. the readme.txt and such. For comparison, on three RPi cards here with modified kernels to get PPS from a GPIO pin, using ntpq -pn I see jitter values of 0.002, 0.002 and 0.002/0.004. The 0.002 seems to be near the sys_jitter limit as reported from ntpq -c rv. That's indeed better. The results I see are probably also influenced by the fact that this RPI also does other things (software defined radio, camera and measuring the light intensity outside). Cards 1 and 2 are just doing NTP, the third card is running a data collector processing signals from a DVB receiver stick, and sending the derived data over a Wi-Fi link to a PC running Plane Plotter using the dump1090 program. This gives a CPU load around 35%. It would be interesting to know how your version handles a busy RPi. Hmmm, I'll see if I can setup an RPI which only does the time keeping and see if that gives better results. Folkert van Heusden === Thanks, Folkert, that's most helpful! One thing which is unclear to me is what do you mean by pin 8? Is that a programming number, or does it refer to the GPIO header? I did try and find this in the RPi documentation, but it's not clear. I'm currently using NTP driver type 22 on the RPi I would like to test with. If I move to the type 28 driver it doesn't matter that PPS is left supported in the Linux kernel. Please confirm there is no need to revert to a kernel without PPS support. Is there a simple way of stopping the OS stealing that GPIO pin - turning off PPS support with a simple edit? What might matter, of course, is that I would need to move the actual PPS signal to a different pin as kernel-PPS and your program would not live together, as both would want to grab that pin. So it may mean making a small hardware change as well if I can't turn off PPS support. One thing you might want to try is to pulse one of the GPIO pins in response to the rising-edge interrupt you get, to see what the delay is when measured by a 'scope. Many thanks for making this available. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
Thanks, Folkert, that's most helpful! One thing which is unclear to me is what do you mean by pin 8? Is that a programming number, or does it refer to the GPIO header? I did try and find this in the RPi documentation, but it's not clear. Check this picture: http://jeffskinnerbox.files.wordpress.com/2012/11/raspberry-pi-rev-1-gpio-pin-out1.jpg GPIO pin 8 is in the upper right block with SPI in it. GPIO 8 (CE0) is written above it. By the numbering on that diagram it is physical pin 24. I'm currently using NTP driver type 22 on the RPi I would like to test with. If I move to the type 28 driver it doesn't matter that PPS is left supported in the Linux kernel. Please confirm there is no need to revert to a kernel without PPS support. Is there a simple way of stopping the OS stealing that GPIO pin - turning off PPS support with a simple edit? If I remember correctly, the kernel patch uses GPIO 18 (PCM_CLK), so using GPIO 8 will work fine with the patched kernel. What might matter, of course, is that I would need to move the actual PPS signal to a different pin as kernel-PPS and your program would not live together, as both would want to grab that pin. So it may mean making a small hardware change as well if I can't turn off PPS support. Maybe, but I'm not an electronics expert (not at all in fact) you can feed both pins? One thing you might want to try is to pulse one of the GPIO pins in response to the rising-edge interrupt you get, to see what the delay is when measured by a 'scope. Ok, I've uploaded version 0.2 which can do so. This version can also, in debug mode, show the offset of the local clock to the PPS timestamp. Folkert van Heusden -- Nagios user? Check out CoffeeSaint - the versatile Nagios status viewer! http://www.vanheusden.com/java/CoffeeSaint/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
Check this picture: http://jeffskinnerbox.files.wordpress.com/2012/11/raspberry-pi-rev-1-gpio-pin-out1.jpg GPIO pin 8 is in the upper right block with SPI in it. GPIO 8 (CE0) is written above it. By the numbering on that diagram it is physical pin 24. [] If I remember correctly, the kernel patch uses GPIO 18 (PCM_CLK), so using GPIO 8 will work fine with the patched kernel. [] Maybe, but I'm not an electronics expert (not at all in fact) you can feed both pins? [] Ok, I've uploaded version 0.2 which can do so. This version can also, in debug mode, show the offset of the local clock to the PPS timestamp. Folkert van Heusden Fine, Folkert. The GPIO pins are numbered in your program exactly as I would expect, and the diagram just confirms that. Yes, the patched kernel can remain, and PPS operation should be unaffected. I was able to drive the two pins (GPIO 18 and GPIO 8) in parallel, and I have a signal level of about 2.5 V from a resistive divider. I'm actually driving it from a Trimble SMT module where the serial is over the USB, and gpsd see the GPS data perfectly. Thanks for the monitoring output. The tie delay between the PPS leading edge and the change of the monitoring line varies between 270 to 390 microseconds, so despite the jitter being reported in the 3-5 microsecond range, the internal clock is perhaps running about 1/3 millisecond behind real time. You will be able to see the performance compared to kernel-PPS here: http://www.satsignal.eu/mrtg/performance_raspi-2.php and a comparison with other stratum-1 Raspberry Pi cards here: http://www.satsignal.eu/mrtg/performance_ntp.php The software compiled and installed without any issues. I've yet to figure out how to get it to auto-start - you might like to add that to your instructions. I may add a section to my Web page with a step-by-step guide, as this is so much easier than have to use a non-standard kernel. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
David, Fine, Folkert. The GPIO pins are numbered in your program exactly as I would expect, and the diagram just confirms that. Yes, the patched kernel can remain, and PPS operation should be unaffected. I was able to drive the two pins (GPIO 18 and GPIO 8) in parallel, and I have a signal level of about 2.5 V from a resistive divider. I'm actually driving it from a Trimble SMT module where the serial is over the USB, and gpsd see the GPS data perfectly. Ah! Is the serial over usb working stable on your rpi? I have lots of problems with usb devices dropping from the usb bus. Also with a powered hub. Thanks for the monitoring output. The tie delay between the PPS leading edge and the change of the monitoring line varies between 270 to 390 microseconds, so despite the jitter being reported in the 3-5 microsecond range, the internal clock is perhaps running about 1/3 millisecond behind real time. You will be able to see the performance compared to kernel-PPS here: http://www.satsignal.eu/mrtg/performance_raspi-2.php cool! and a comparison with other stratum-1 Raspberry Pi cards here: http://www.satsignal.eu/mrtg/performance_ntp.php The software compiled and installed without any issues. I've yet to figure out how to get it to auto-start - you might like to add that to your instructions. I may add a section to my Web page with a step-by-step guide, as this is so much easier than have to use a non-standard kernel. Will do. For now: edit /etc/rc.local and add the following (BEFORE the exit 0 statement and AFTER the #!/bin/sh line): /usr/local/rpi_gpio_ntp -N 1 -g 8 (replace '8' by the gpio pin) Folkert van Heusden -- Curious about the inner workings of your car? Then check O2OO: it'll tell you all that there is to know about your car's engine! http://www.vanheusden.com/O2OO/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
David, [] Ah! Is the serial over usb working stable on your rpi? I have lots of problems with usb devices dropping from the usb bus. Also with a powered hub. [] The software compiled and installed without any issues. I've yet to figure out how to get it to auto-start - you might like to add that to your instructions. I may add a section to my Web page with a step-by-step guide, as this is so much easier than have to use a non-standard kernel. Will do. For now: edit /etc/rc.local and add the following (BEFORE the exit 0 statement and AFTER the #!/bin/sh line): /usr/local/rpi_gpio_ntp -N 1 -g 8 (replace '8' by the gpio pin) Folkert van Heusden === I'm using the USB GPS right off the USB port, no hub. I've had no stability problems (the GPS stops working after some number of days, 25 typically, but maybe that's why it was cheap in any case! RasPi-3 here has a Wi-Fi dongle and DVB-T TV receiver stick connected, and that appears to be stable as well. I'm using a 5.25V 2A PSU as supplied by ModMyPi.com Thanks for the auto-start information. I'd previously seen more complicated ways of doing this - scripts involving the ability to stop and restart the software. BTW: it's /user/local/bin/rpi_gpio_ntp, for the executable, I think. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
Quoting folkert folk...@vanheusden.com: : +127.127.28.1.PPS.0 l48 3770.000 2.231 0.005 : I'm surprised that the jitter goes down to 0.005 as I'm now measuring the PPS from userspace. My program runs with real time scheduling and maximum priority but still the kernel needs to do a context switch etc. when it receives the pps pulse. I got similiar results with measuring the PPS timestamp in a userland real-time (SCHED_RR) process. All my hardware is different from yours, but it sounds like our software is close in architecture. Here's the graph of jitter over two days: http://dan.drown.org/stm32/run5/time-variance.png I'm using the setting minpoll 4 maxpoll 4 for a 16 second cycle and sending the median of those 16 offsets to ntpd. I'm also collecting the max and min offsets, and graphed them here: http://dan.drown.org/stm32/run5/usb.png As a comparison, I tried timestamping in the kernel and put the min/max graphs for kernel vs userland side by side: http://dan.drown.org/stm32/run6/usb-compare.png The jitter for the kernel timestamping run is improved as well: http://dan.drown.org/stm32/run6/time-variance-compare.png More info on the userland/kernel comparison: http://dan.drown.org/stm32/run6.html ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] raspberry pi, adafruit gps ntp
Though I have been tied up with the wwvb stuff this is also on my list of to do's. I have had the RPI up and running and am looking forward to making a small low power time server. Thanks Paul WB8TSL On Mon, Jun 17, 2013 at 5:31 PM, li...@lazygranch.com wrote: ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] raspberry pi, adafruit gps ntp
Hi, Ok today my friend Henk (Henk are you still subscribed here?) soldered the raspberry pi on my adafruit ultimate gps breakout v3. Apart from the soldering things were totally easy to get to work: only a few tweaks to cmdline.txt and inittab and the serial data streamed in. I decided _not_ to patch the kernel after a couple of issues with missing include files and such. But as only watching the nmea stream gives bad results, I needed to find an alternative for the PPS signal. So I wrote a little program which watches the GPIO port using poll (which waits for an interrupt) and then pokes in the shared memory segment of ntpd. After 51 minutes of ntpd run-time this gives: remote refid st t when poll reach delay offset jitter == *firewall.intran 192.168.64.2 3 u7 64 3770.560 -0.506 0.493 -belle.intranet. 192.168.64.2 3 u 58 64 3770.560 -0.470 0.405 -time2.intranet. 194.109.20.183 u 56 64 3771.034 -1.282 1.392 +auth1.xs4all.nl 193.67.79.2022 u 28 64 377 17.580 -0.160 0.490 xSHM(0) .NMEA. 0 l1 16 3770.000 -359.47 10.670 +SHM(1) .PPS.0 l18 3770.0002.964 0.061 I started the program with statistics logging enabled so I will produce some nice graphs after a day or so. Folkert van Heusden -- Feeling generous? - http://www.vanheusden.com/wishlist.php -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
