Re: [time-nuts] Beaglebone NTP server
Quoting Paul : From the time-nut perspective what's the interest in high resolution NTP? I mean beyond the "can I do this?" appeal. From a practical standpoint, I don't personally have any application that benefits from sub-1s accuracy. I'm just doing it for fun and learning. ___ 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] Beaglebone NTP server
As a test of load, I sent around 650 ntp queries per second (give or take 20 q/s) to the BBB. CPU usage was around 87% idle. There were no dropped packets for the 108,000 sent. Round-trip time was between 287us and 199us. Traffic was around 470kbit/s. Assuming clients have a query rate of 1 per 256s on average, that rate is good for around 150k clients. That also leaves plenty of CPU free for bursts. NTP isn't exactly a heavy protocol :) Is this better or worse than other NTP server platforms? I haven't tested them, so I have no idea. Quoting Chris Albertson : Those sub 1 u-second numbers are very good. They argue for using the BBB as an NTP server but I wonder if it really is the best. I think the numbers that matter are measures of the close on the computers who use your BBB as a server. In other words the goal is to synchronize a set of computers. Can The little BBB push accurate time out to a set of user computers and keep then in sync better then some other NTP server platform? On Wed, Dec 10, 2014 at 5:58 PM, Dan Drown wrote: Quoting Paul : Using a PRU seems like overkill if all you want from the BBB is NTP. The standard pps-gpio should move the system clock precision below system/network jitter (.5 to 1 microsecond). The next step is using a timer (TIMER4) which should get you into .1 microsecond offsets. As a note to people wanting to use the timer hardware on the BBB - I have a driver for it at https://github.com/ddrown/pps-gmtimer I wrote up the results in using it at http://blog.dan.drown.org/ beaglebone-black-timer-capture-driver/ The summary of it is: pps-gpio - 50% of the time local clock offset within +/- 0.07us, 98% within +/- 0.61us pps-gmtimer - 50% of the time local clock offset within +/- 0.04us, 98% within +/- 0.43us Also, if you're using pps-gpio, you might want to disable cpufreq and force your processor to 1GHz. It'll help with interrupt latency and jitter. cpufreq ondemand, 300MHz-1GHz - http://dan.drown.org/bbb/run9/ interrupt-latency.png 98% of interrupts handled 12.92us-23.21us after the event happened. cpufreq forced 1GHz - http://dan.drown.org/bbb/run8/interrupt-latency.png 98% of interrupts handled 6.04us-8.58us after the event happened. ___ 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. -- Chris Albertson Redondo Beach, California ___ 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.
Re: [time-nuts] Beaglebone NTP server
The CPU temperature as measured by the on-CPU sensor went from about 55C to about 60C. 300MHz to 1GHz, ondemand, CPU in red http://dan.drown.org/bbb/run9/temp.png 1GHz fixed, CPU in red http://dan.drown.org/bbb/run8/temp.png For current drain, I only have numbers at the wall wart measured by a kill-a-watt. The entire system goes from 0.02A/1W to 0.04A/2W. Power Factor is in the 0.5~0.4 region. For the pins, that is correct. I chose P8.7 because it was TIMER4's input, and I can switch between pps-gpio and pps-gmtimer by changing which dts overlay I'm using. Quoting Graham / KE9H : When you forced/locked the CPU frequency at 1 GHz, did you by any chance measure what it did to the CPU case/package temperature? Or current drain? I note that you used BBB pin P8.7 for PPS input. That allowed you to use it for either pps-gpio or TIMER4 pps-gmtimer, by just changing the pin-mux? --- Graham == On Wed, Dec 10, 2014 at 7:58 PM, Dan Drown wrote: Quoting Paul : Using a PRU seems like overkill if all you want from the BBB is NTP. The standard pps-gpio should move the system clock precision below system/network jitter (.5 to 1 microsecond). The next step is using a timer (TIMER4) which should get you into .1 microsecond offsets. As a note to people wanting to use the timer hardware on the BBB - I have a driver for it at https://github.com/ddrown/pps-gmtimer I wrote up the results in using it at http://blog.dan.drown.org/ beaglebone-black-timer-capture-driver/ The summary of it is: pps-gpio - 50% of the time local clock offset within +/- 0.07us, 98% within +/- 0.61us pps-gmtimer - 50% of the time local clock offset within +/- 0.04us, 98% within +/- 0.43us Also, if you're using pps-gpio, you might want to disable cpufreq and force your processor to 1GHz. It'll help with interrupt latency and jitter. cpufreq ondemand, 300MHz-1GHz - http://dan.drown.org/bbb/run9/ interrupt-latency.png 98% of interrupts handled 12.92us-23.21us after the event happened. cpufreq forced 1GHz - http://dan.drown.org/bbb/run8/interrupt-latency.png 98% of interrupts handled 6.04us-8.58us after the event happened. ___ 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 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] Beaglebone NTP server
Quoting Paul : Using a PRU seems like overkill if all you want from the BBB is NTP. The standard pps-gpio should move the system clock precision below system/network jitter (.5 to 1 microsecond). The next step is using a timer (TIMER4) which should get you into .1 microsecond offsets. As a note to people wanting to use the timer hardware on the BBB - I have a driver for it at https://github.com/ddrown/pps-gmtimer I wrote up the results in using it at http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/ The summary of it is: pps-gpio - 50% of the time local clock offset within +/- 0.07us, 98% within +/- 0.61us pps-gmtimer - 50% of the time local clock offset within +/- 0.04us, 98% within +/- 0.43us Also, if you're using pps-gpio, you might want to disable cpufreq and force your processor to 1GHz. It'll help with interrupt latency and jitter. cpufreq ondemand, 300MHz-1GHz - http://dan.drown.org/bbb/run9/interrupt-latency.png 98% of interrupts handled 12.92us-23.21us after the event happened. cpufreq forced 1GHz - http://dan.drown.org/bbb/run8/interrupt-latency.png 98% of interrupts handled 6.04us-8.58us after the event happened. ___ 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] Beaglebone NTP server
If you're using the pps-gpio module, the hardware can support "up to Two Interrupt Inputs per Bank". So if you're not using the gpio for anything else, any of the gpio should work. If you want to use the timer hardware (and pps-dmtimer module), each timer has an assigned pin. Quoting Graham / KE9H : For those of you that have gotten the BeagleBone Black up and running as an ntp server with the 1PPS signal input in kernel space, what gpio input pin is being used? I guess I am asking if the kernel "pps-gpio" has a specific preferred pin, or whether it can be mapped to any available gpio pin. Thanks, --- Graham / KE9H == On Tue, Dec 9, 2014 at 11:18 AM, Bob Darlington wrote: Hourly cron jobs, perhaps? -Bob On Tue, Dec 9, 2014 at 8:04 AM, David J Taylor < david-tay...@blueyonder.co.uk> wrote: > Thanks for pointing this out David, > Compiling an new kernel was holding me back. I followed your instructions > and > everything works beautiful. The PI that is running the PPS timekeeping > with NTP > is serving as a VLF receiver as well. Taxing the poor CPU, but with > kernel PPS support > the NTP daemon has become way happier! (see attachment) > > 73, Frits W1FVB > == > > Oh, yes! That's much better, Frits! Delighted to have helped! > > (Although it now shows up an hourly periodicity - any idea what might be > causing that?) > > 73, > David GM8ARV > > -- > 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. > ___ 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 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] Beaglebone Black driver for hardware timer capture
Quoting Iain Young : : Is your code able to support multiple inputs simultaneously ? FreeBSD's doesn't due to some architecture issue with the timing subsystem as I understand it. Or is it like the FreeBSD code, and I have to select exactly one of TIMER4-TIMER7 input pins to drive the PPS ? In theory it should support multiple timers, each with their own /dev/ppsX file. I haven't tested that part yet, though :) The timer hardware to use is selected with the device tree overlay. Creating multiple pps-gmtimer device tree elements, each with their own timer should be possible. I'm not sure how much having two or more timer capture interrupts at the same time will affect timing accuracy. That's also something that needs experimenting with. The calculation of when the event happened is done in the interrupt handler, and it subtracts how long ago the event happened from the current time. Since I'm not currently adjusting for local clock speed, this adds 1 nanosecond of error for every 17 microseconds the interrupt is delayed (assuming 60ppm local clock error). The Beaglebone also has the facility for an external clock input. Are you planning on doing any work in order to get the Linux kernel to select the TCLKIN as the clock ? It should be pretty easy to switch to TCLKIN, the function "omap_dm_timer_set_source" is already there for it. Either the main timer used for the system clock (in arch/arm/mach-omap2/timer.c) or this module could be changed to use TCLKIN. If this module was extended to also be a clocksource, it could be used for system time as well. I don't have any hardware to experiment with TCLKIN on hand, so I won't be doing that this month at least. ___ 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] Beaglebone Black driver for hardware timer capture
I wrote a kernel driver for the BBB timer hardware. It produces pps events for things like ntpd to consume. The source for it is at https://github.com/ddrown/pps-gmtimer A side effect of this driver is it measures the interrupt latency and jitter on the BBB hardware. The attached file interrupt-latency.png contains an interrupt latency histogram and cumulative distribution function. This interrupt latency should be similar to what the pps-gpio driver experiences on this hardware. The difference is the timer hardware driver can remove the effects of the interrupt latency. The graphs of offset over 7 days worth of samples don't show a huge difference. The *-timer.png file is from pps-gmtimer and the *-gpio.png file is from pps-gpio. The stddev of the offsets are 244ns from the gpio run and 143ns from the timer run. The BBB hardware supports hardware IEEE1588/PTP timestamps, so people might be interested in that as well. The driver for it is already in Linux, but not enabled in the default BBB kernel config. Let me know if you have any questions. Unrelated to the PPS driver: all the feedback on the software frequency temperature compensation has been useful. 90% of the time, the local clock is within 173ppb. 98% of the time, it's within 218ppb. I think I can narrow this range even further with a temperature rate of change variable. All the graphs are at http://dan.drown.org/bbb/latest/___ 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] Digital temperature compensation
I think you have a good point - any model is going to have a larger error than the data itself. I'll be looking into this. Quoting Chris Albertson : If this is just for holdover then I don't think you even want a general solution. Have the controller always keep the last few days of data for temperature vs. EFC value. Then if GPS fails use the most recent data for the current temperature. This makes for a self adapting system accounting for aging too. Not just crystal aging but the aging of the resisters, the temperature sensor itself and other components. I don't think holdover should fall back onto a model that was created from data that might be months or years old. Use hours or days old data. This will give the desired response which is this: If the temperature is constant when the GPS fails the EFC value as determined by your holdover temperature modeling should give you the EXACT same EFC value as just before the GPS failure. I don't think you can do that with a model. You'd nee to use logged data. On Sat, Nov 1, 2014 at 4:01 PM, Bob Camp wrote: Hi > On Nov 1, 2014, at 5:09 PM, Dan Drown wrote: > > Ok, I hadn't considered rate of change. It’s one of the limits on this sort of thing in general. It’s even more of an issue with a coupled mode like the one you show. Since there are an enormous number of possible variables, it’s always tough to know exactly how much of an issue you will have. One common answer - run your profile runs at the temperature change rate you are most likely to see in practice. Another very common answer - don’t use that crystal, get one that does not have the problem. You can get parts with slopes <0.1 ppm / C over 10 to 50 C. You might have to spend some quality time sorting them out …. Bob > This data is currently 3 day's worth and seems to repeat itself on both days at the same temperature point. Attached is a time based graph to show that. The ppm axis (on the right) is inverted to make it easier to see the relationship between the two. > > > Quoting Bob Camp : >> Hi >> >> This sort of thing is normally done with a precisely controlled temperature chamber and multi day temperature ramp runs. Even then there is a bit of “wonder what that was, let’s try it again”. >> >> If you are looking at a crystal oscillator, what you have is a perturbation in the frequency / temperature curve. The response you get will be temperature rate of change dependent. >> >> Bob >> >>> On Nov 1, 2014, at 4:40 PM, Dan Drown wrote: >>> >>> I'm experimenting with using a temperature sensor to estimate local oscillator frequency changes. My goal is to have a decent holdover clock for a NTP server with not so great GPS antenna placement. >>> >>> I've been sampling temperature every minute, measured by a DS18B20. I've been measuring local clock frequency differences, using chronyd's logs from the GPS's PPS. At 28C through 21C, I get a pretty good result that fits a quadratic polynomial decently (0.117 ppm stddev). I've attached the graph of that as "temp-clock-warmer.png". >>> >>> With the colder temperatures, there's a sudden drop off in frequency that I'm having a hard time finding a equation that fits as nicely. All the examples I can find on the web look like third degree polynomials, while my data doesn't seem to fit that exactly. The best result I've had so far (0.198 ppm stddev) is attached as "temp-clock.png" and uses the function: >>> >>> f(x) = -abs(a * (x - 20.88)) + b * ((x - 20.88)**2) + c * ((x - 20.88)**3) >>> a = 0.888582 >>> b = 0.113806 >>> c = -0.00445763 >>> >>> Does anyone have any advice on how to better model this? Has anyone seen this behavior? >>> >>> I can provide the raw data if that would help any. >>> ___ >>> 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 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 fol
Re: [time-nuts] Digital temperature compensation
I gave zunzun a try and the one with the lowest root mean squared error was: f(x) = a( x**0.5) + b( x ) + c( sin(x) ) + d( cos(x) ) It got 0.202 RMSE, so I guess I'll stick with my original function as it seems to be closer to what I expect will happen at colder/hotter temps. You have a good point about temperatures outside my data samples. Once it gets hot again in the summertime, I'm sure I'll have to re-evaluate this. Quoting Mark Sims : You could try submitting your data to zunzun.com It will fit it to around 40,000 different curves and find the best ones. Beware that with all curve fitting formulas, once your live data starts to wander out of the range of your original curve fit data, things can go rather badly... ___ 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] Digital temperature compensation
Ok, I hadn't considered rate of change. This data is currently 3 day's worth and seems to repeat itself on both days at the same temperature point. Attached is a time based graph to show that. The ppm axis (on the right) is inverted to make it easier to see the relationship between the two. Quoting Bob Camp : Hi This sort of thing is normally done with a precisely controlled temperature chamber and multi day temperature ramp runs. Even then there is a bit of “wonder what that was, let’s try it again”. If you are looking at a crystal oscillator, what you have is a perturbation in the frequency / temperature curve. The response you get will be temperature rate of change dependent. Bob On Nov 1, 2014, at 4:40 PM, Dan Drown wrote: I'm experimenting with using a temperature sensor to estimate local oscillator frequency changes. My goal is to have a decent holdover clock for a NTP server with not so great GPS antenna placement. I've been sampling temperature every minute, measured by a DS18B20. I've been measuring local clock frequency differences, using chronyd's logs from the GPS's PPS. At 28C through 21C, I get a pretty good result that fits a quadratic polynomial decently (0.117 ppm stddev). I've attached the graph of that as "temp-clock-warmer.png". With the colder temperatures, there's a sudden drop off in frequency that I'm having a hard time finding a equation that fits as nicely. All the examples I can find on the web look like third degree polynomials, while my data doesn't seem to fit that exactly. The best result I've had so far (0.198 ppm stddev) is attached as "temp-clock.png" and uses the function: f(x) = -abs(a * (x - 20.88)) + b * ((x - 20.88)**2) + c * ((x - 20.88)**3) a = 0.888582 b = 0.113806 c = -0.00445763 Does anyone have any advice on how to better model this? Has anyone seen this behavior? I can provide the raw data if that would help any. ___ 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 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] Digital temperature compensation
I'm experimenting with using a temperature sensor to estimate local oscillator frequency changes. My goal is to have a decent holdover clock for a NTP server with not so great GPS antenna placement. I've been sampling temperature every minute, measured by a DS18B20. I've been measuring local clock frequency differences, using chronyd's logs from the GPS's PPS. At 28C through 21C, I get a pretty good result that fits a quadratic polynomial decently (0.117 ppm stddev). I've attached the graph of that as "temp-clock-warmer.png". With the colder temperatures, there's a sudden drop off in frequency that I'm having a hard time finding a equation that fits as nicely. All the examples I can find on the web look like third degree polynomials, while my data doesn't seem to fit that exactly. The best result I've had so far (0.198 ppm stddev) is attached as "temp-clock.png" and uses the function: f(x) = -abs(a * (x - 20.88)) + b * ((x - 20.88)**2) + c * ((x - 20.88)**3) a = 0.888582 b = 0.113806 c = -0.00445763 Does anyone have any advice on how to better model this? Has anyone seen this behavior? I can provide the raw data if that would help any. ___ 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] Ublox neo-7M GPS
Quoting Tony : I don't have any means to do that at the moment - when I get time I'll try programming my STM32F4 discovery board (168MHz ARM Cortex M4) to take some measurements. However as I haven't used the timers on that yet it'll take a bit of time to get it right! Be careful interpreting those results. I have a stm32f4 discovery and its timer occasionally wanders very far. The measurements I have are using the internal PLL as the timer's source, which is driven by the external crystal. I assume it wouldn't be an issue if you used an external clock source for the timer, but I haven't tested that. I captured timer measurments of PPS signals from a Navspark GPS over 20 hours with a timer capture channel on TIM2. TIM2 was setup with a 10.5Mhz rate (84Mhz / 8). Mostly the intervals between PPS were within 1ppm (10hz). Looking at a random 4 second interval where they were not within 1ppm: 10500782HZ (normal) 10499731HZ (-100ppm) 10501831HZ (+99ppm) 10500781HZ (normal) This happened 7 times within 20 hours, with the same pattern. This also happens when I switch out the Navspark GPS for a different navigation-grade GPS. In case you're interested in the stm32 code, it's based on the STM libraries: https://github.com/ddrown/usb-gps/blob/master/src/pps.c https://github.com/ddrown/usb-gps/blob/master/src/mytimer.c ___ 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 : : +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] time transfer over USB
On May 14, Peter Monta wrote:
So a USB-based GPS should:
- maintain a cycle count of its local crystal oscillator (e.g. with
a timer peripheral)
- report this count when requested
- timestamp PPS edges from the GPS module, and report these timestamps when
requested
I was already tinkering with stuff along these lines, so I threw
together some code that just prints to a USB emulated serial port on
every PPS pulse as well as a simple program on the PC side to
timestamp it. I know this isn't ideal, I just wanted to get a
starting point. My goal is to get the error under 1ms ("NTP" grade
instead of "timenut" grade :).
This is the result (red "bar" of 41k samples), compared to NTP
loopstats info (green line, cable modem connection):
http://dan.drown.org/stm32/run2/time-drift.png
From that picture, you can see that it's around 2ms worth of
inaccuracy. I'm working on adding your recommendations to see if I
can get that number lower.
More info and graphs if anyone's interested:
http://dan.drown.org/stm32/run2.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.
