Re: [time-nuts] Beaglebone NTP server
Dan:
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 dan-timenuts@drown.org wrote:
Quoting Paul tic-toc@bodosom.net:
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.
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 dan-timenuts@drown.org wrote:
Quoting Paul tic-toc@bodosom.net:
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
Hello
Try to run ntpd with realtime priority (options '-N' or '-P priority').
Your an hourly jobs can be executed several slower but it may improve
the time synchronization.
2014-12-09 23:45 GMT+04:00, Frister frister@gmx.net:
Hi David,
Yes, You mean the hourly dips? That is caused by the the VLF receive
software that
is running on the same PI. It makes hourly recordings of DC to 24 Khz
with a USB soundcard. The CPU is running at max capacity most of the
time.
Perhaps it is now time for a dedicated PI, that only has the task of
playing Stratum One.
If anyone is interested:
https://pivlf.wordpress.com/
73, Frits W1FVB
On 12/9/14, David J Taylor david-taylor@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-taylor@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.
--
vbradio.wordpress.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.
On Wed, Dec 10, 2014 at 10:15 PM, Chris Albertson <albertson.chris@gmail.com
wrote:
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?
When I think of what we have been using to run NTP down through the years,
this is almost funny. The BBB is little in physical package size only. Its
processing power is not inconsequential.
Fuzzballs anyone?
--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
On Wed, Dec 10, 2014 at 10:21 PM, Michael Tatarinov kukabu@gmail.com
wrote:
Hello
Try to run ntpd with realtime priority (options '-N' or '-P priority').
Your an hourly jobs can be executed several slower but it may improve
the time synchronization.
And given the price, why try to run multiple, time-critical applications on
one BBB or RPi? Just get lots of them.
--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
Le 11 déc. 2014 à 05:47, Brian Lloyd brian@lloyd.aero a écrit :
On Wed, Dec 10, 2014 at 10:15 PM, Chris Albertson <albertson.chris@gmail.com
wrote:
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?
When I think of what we have been using to run NTP down through the years,
this is almost funny. The BBB is little in physical package size only. Its
processing power is not inconsequential.
The question for anyone using them for other than personal use may be long term reliability. My three Soekris 4501s all died from power supply failiurs after 5 years contnuous use, while the 4801s have 6 years under the belt and still going strong. Will the RPIs and BBBs systematic issues or still be running after the same time? Of course 5 years is not that bad when S1 NTP servers are dedicated to that. Also the cost is so low that replacement isn’t a problem. A no brainer really.
Fuzzballs anyone?
--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
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.
2014-12-11 8:48 GMT+04:00, Brian Lloyd brian@lloyd.aero:
On Wed, Dec 10, 2014 at 10:21 PM, Michael Tatarinov kukabu@gmail.com
wrote:
Hello
Try to run ntpd with realtime priority (options '-N' or '-P priority').
Your an hourly jobs can be executed several slower but it may improve
the time synchronization.
And given the price, why try to run multiple, time-critical applications on
one BBB or RPi? Just get lots of them.
I think an hourly jobs isn't time-critical and must have a low priority.
Why a lots if one (with tuning) is enough?
Getting a BBB to take 10MHz refclk input (in the fashion of
http://www.febo.com/pages/soekris/)
and being able to timestamp multiple PPS signals via the PRUs would
make for a pretty awesome time-nuts toy.
This is quite do-able and I posted a few weeks ago with the details of
where to poke the soldering iron.
https://www.febo.com/pipermail/time-nuts/2014-November/088385.html
Once you attach a bit of coax the only limit is how deep your pockets
are, you can use whatever reference you want to clock the BBB. An OXCO
will likely provide the best performance for most of us (for the same
reasons as using one in a GPSDO).
For kicks, I ran my BBB locked directly to a GPS module for a short
while. That is, using a x12 PLL to create 24mhz from a ublox module
configured to output 2mhz. (I don't recommend anyone actually uses this
configuration btw, but it was fun to actually see it work)
Cheers
Simon
On 11/12/2014 04:15, Chris Albertson wrote:
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?
The BBB scores over the Pi here in having real hardware ethernet instead
of USB ethernet.
Better, the BBB has hardware support for IEEE1588 timestamping so you
can ditch NTP and distribute time using the BBB as a PTP grandmaster.
The software is mature, but unfortunately a kernel rebuild is required
to enable the appropriate drivers.
The attached graph shows an overnight test using two BBBs connected via
a normal (i.e. non-IEEE1588) gigabit switch. The offset graphed is as
reported by PTP on the slave, the black line is a moving 100 point
average and the scale is in ns. The stddev offset over the period is
about 260ns.
Cheers
Simon
Just to echo that using the PRU cores is the wrong way to go, the BBB
has a multitude of hardware timers that will give better performance for
less hassle.
Having said that, by far the Number One thing to consider is controlling
the impact of temperature changes. If you sort that, the rest is icing
on the cake.
In order of complexity:
Out the box, using gpio-pps, the BBB is a good NTP server that will hold
its own against other SoC solutions.
Stick it in a box to control the temperature a bit and run Dan Drown's
gmtimer-pps, you'll get a great NTP server.
https://www.febo.com/pipermail/time-nuts/2014-December/089217.html
This is an easy, quick win that will give excellent results.
Add PTP and you should be able to sync time to other boxes at sub
microsecond levels.
But because we don't stop with 'just' great solutions ...
Dan has been looking at software compensation to control the temperature
impact.
https://www.febo.com/pipermail/time-nuts/2014-November/087745.html
I took a more brute force approach and clocked the BBB from a more
stable reference.
https://www.febo.com/pipermail/time-nuts/2014-November/088385.html
Cheers
Simon
On 10/12/2014 23:56, Paul wrote:
On Wed, Dec 10, 2014 at 4:58 PM, Brian Lloyd brian@lloyd.aero wrote:
Well, I am hoping to get to the point where the path to using the BBB as an
NTP server using the PRU for more precise timing
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.
Naturally if you're doing significant computing (heh) on the BBB you might
want to use a real time unit.
The current portion of this thread is part of the June-2013 hread started
by Gabs Ricalde about using TIMER4 for capture with 10MHz/1PPS input.
https://www.febo.com/pipermail/time-nuts/2013-June/077430.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.