time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] Beaglebone NTP server

JL
Jim Lux
Thu, Dec 11, 2014 1:13 PM

On 12/10/14, 9:45 PM, Mike Cook wrote:

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.

Ah, but will the exact same single board computer be available for
replacement in 5 years?  Or will it be Rev F instead of Rev B, with
"just a few tweaks to improve performance", but also enough that it's
not "drop the image on it and run"

What about 10 years?
15?

Philosophically it might be a straightforward thing, but it might not be
as easy as one might hope.

Legacy support with processor boards is a real challenge.

On 12/10/14, 9:45 PM, Mike Cook wrote: > >> 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. > Ah, but will the exact same single board computer be available for replacement in 5 years? Or will it be Rev F instead of Rev B, with "just a few tweaks to improve performance", but also enough that it's not "drop the image on it and run" What about 10 years? 15? Philosophically it might be a straightforward thing, but it might not be as easy as one might hope. Legacy support with processor boards is a real challenge.
BL
Brian Lloyd
Thu, Dec 11, 2014 2:14 PM

On Thursday, December 11, 2014, Jim Lux jimlux@earthlink.net wrote:

Ah, but will the exact same single board computer be available for
replacement in 5 years?

Most likely not. These days I can't imagine a manufacturer making the same
SBC or mobo board for more than a year. If you consider BBB to be the
logical continuance of the original beagle board then it is going on two
years but is at rev C.

Or will it be Rev F instead of Rev B, with "just a few tweaks to improve
performance", but also enough that it's not "drop the image on it and run"

What about 10 years?
15?

If that is an issue, buy a spare and keep it in the same box with each
running one. Heck, buy two spares.

Philosophically it might be a straightforward thing, but it might not be
as easy as one might hope.

Legacy support with processor boards is a real challenge.


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.

--
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)

On Thursday, December 11, 2014, Jim Lux <jimlux@earthlink.net> wrote: > > Ah, but will the exact same single board computer be available for > replacement in 5 years? Most likely not. These days I can't imagine a manufacturer making the same SBC or mobo board for more than a year. If you consider BBB to be the logical continuance of the original beagle board then it is going on two years but is at rev C. > Or will it be Rev F instead of Rev B, with "just a few tweaks to improve > performance", but also enough that it's not "drop the image on it and run" > > What about 10 years? > 15? If that is an issue, buy a spare and keep it in the same box with each running one. Heck, buy two spares. > Philosophically it might be a straightforward thing, but it might not be > as easy as one might hope. > > Legacy support with processor boards is a real challenge. > _______________________________________________ > 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. > -- Brian Lloyd Lloyd Aviation 706 Flightline Drive Spring Branch, TX 78070 brian@lloyd.aero +1.210.802-8FLY (1.210.802-8359)
CA
Chris Albertson
Thu, Dec 11, 2014 2:45 PM

Your logic would disqualify EVERY computer made today.  What will still be
in production in 10 years?

If you care a lot about reliantly you install three NTP servers on your
network.  Further you make sure each server is DIFFERENT and uses a
different brand of GPS.  You configure them all as peers.  You'd still have
a redundant system after a failure.  I don't see why you'd want to replace
the failed it with one that is identical because in several years there
will likely be something even better at lower cost.

The above comment about BBB having a good hardware Ethernetreally does make
the BBB seem suited to this task.  ButNTP is such a small load that you
can run other services too.  A file server (NAS) seems reasonable.

On Thu, Dec 11, 2014 at 5:13 AM, Jim Lux jimlux@earthlink.net wrote:

Ah, but will the exact same single board computer be available for
replacement in 5 years?  Or will it be Rev F instead of Rev B, with "just a
few tweaks to improve performance", but also enough that it's not "drop the
image on it and run"

What about 10 years?
15?

Philosophically it might be a straightforward thing, but it might not be
as easy as one might hope.

Legacy support with processor boards is a real challenge.


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

Your logic would disqualify EVERY computer made today. What will still be in production in 10 years? If you care a lot about reliantly you install three NTP servers on your network. Further you make sure each server is DIFFERENT and uses a different brand of GPS. You configure them all as peers. You'd still have a redundant system after a failure. I don't see why you'd want to replace the failed it with one that is identical because in several years there will likely be something even better at lower cost. The above comment about BBB having a good hardware Ethernetreally does make the BBB seem suited to this task. ButNTP is such a small load that you can run other services too. A file server (NAS) seems reasonable. On Thu, Dec 11, 2014 at 5:13 AM, Jim Lux <jimlux@earthlink.net> wrote: > > Ah, but will the exact same single board computer be available for > replacement in 5 years? Or will it be Rev F instead of Rev B, with "just a > few tweaks to improve performance", but also enough that it's not "drop the > image on it and run" > > What about 10 years? > 15? > > Philosophically it might be a straightforward thing, but it might not be > as easy as one might hope. > > Legacy support with processor boards is a real challenge. > > _______________________________________________ > 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
DD
Dan Drown
Thu, Dec 11, 2014 2:45 PM

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 ke9h.graham@gmail.com:

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.


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.

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 <ke9h.graham@gmail.com>: > 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. >> > _______________________________________________ > 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. >
P
Paul
Thu, Dec 11, 2014 2:57 PM

On Thu, Dec 11, 2014 at 8:13 AM, Jim Lux jimlux@earthlink.net wrote:

Philosophically it might be a straightforward thing, but it might not be
as easy as one might hope.

Legacy support with processor boards is a real challenge.

Which is why you don't do it this (ot that) way.  The little SoC boxes are
great but for most people doing NTP S1 they're either overkill (almost
everyone not a national lab) or inadequate.  Michael Tharp's products have
shown the way forward for anyone that doesn't want to go with Meinberg et.al
.

On Thu, Dec 11, 2014 at 8:13 AM, Jim Lux <jimlux@earthlink.net> wrote: > Philosophically it might be a straightforward thing, but it might not be > as easy as one might hope. > > Legacy support with processor boards is a real challenge. > Which is why you don't do it this (ot that) way. The little SoC boxes are great but for most people doing NTP S1 they're either overkill (almost everyone not a national lab) or inadequate. Michael Tharp's products have shown the way forward for anyone that doesn't want to go with Meinberg et.al .
JL
Jim Lux
Thu, Dec 11, 2014 2:59 PM

On 12/11/14, 6:14 AM, Brian Lloyd wrote:

On Thursday, December 11, 2014, Jim Lux jimlux@earthlink.net wrote:

Ah, but will the exact same single board computer be available for
replacement in 5 years?

Most likely not. These days I can't imagine a manufacturer making the same
SBC or mobo board for more than a year. If you consider BBB to be the
logical continuance of the original beagle board then it is going on two
years but is at rev C.

Or will it be Rev F instead of Rev B, with "just a few tweaks to improve
performance", but also enough that it's not "drop the image on it and run"

What about 10 years?
15?

If that is an issue, buy a spare and keep it in the same box with each
running one. Heck, buy two spares.

I'm not sure that's a valid approach.. because eventually, the spares
fail, or there's some crippling problem (year 2000 problems hardcoded in
something, etc)

At JPL, we are somewhat cursed by the fact that we don't depreciate our
test equipment and computers. It's expensed in the year you buy it, and
then it is essentially free forever (subject to calibration and
maintenance costs).

Therefore we have a lot of really old equipment around, and new systems
are designed and built incorporating the old equipment.  But when the
last unit of that old model fails, now you have to update everything and
jump multiple generations at one time, which is difficult. You've got a
lot of learned history and designs that rely on idiosyncracies of a
particular model (e.g. the 8663A, which happens to do phase continuous
sweeping and can be phase modulated directly).

And now, your venerable 8663 fails.

The new replacement model (e.g. the E8663B) is functionally quite
similar, has all the same specs (maybe even better in some cases), but,
oops, it doesn't do phase continuous sweeping (because the synthesis
chain is different).

Rather than figure out how to solve the need with the newer gear, this
leads to a scrounge fest.  You get the institutional inventory and
surplus list out and start calling up people who have seem to have
another 8663A that hopefully they're not using and/or that it actually
works.
We've got stacks of dead 8663s sitting around, in, I think, the forlorn
hope that someone will be able to cannibalize them for repair parts.

The problem is even worse with PCs, because the support cycle time is
shorter.

The wailing, gnashing of teeth, and pulling of hair when NT 4.0 and
later WinXP was declared OS non grata was amazing. Data acquisition
systems, lab controllers, etc. all running WinXP and connected to the
network as part of their function.  Upgrading your software from NT to
WinXP to Vista then to 7 then to 8 isn't as painful as jumping from NT to 8.

Linux isn't a whole lot better. If you have a system you cobbled
together in 2004 that was tied, say, to the typical audio system of the
time, odds are that you're in for a real challenge to drop it into a
modern distro with modern motherboard hardware.  Which version of glibc?
OSS audio? parallel port drivers? Oh, your new mobo doesn't HAVE a
parallel printer port?

On 12/11/14, 6:14 AM, Brian Lloyd wrote: > On Thursday, December 11, 2014, Jim Lux <jimlux@earthlink.net> wrote: > >> >> Ah, but will the exact same single board computer be available for >> replacement in 5 years? > > > Most likely not. These days I can't imagine a manufacturer making the same > SBC or mobo board for more than a year. If you consider BBB to be the > logical continuance of the original beagle board then it is going on two > years but is at rev C. > > >> Or will it be Rev F instead of Rev B, with "just a few tweaks to improve >> performance", but also enough that it's not "drop the image on it and run" >> >> What about 10 years? >> 15? > > > If that is an issue, buy a spare and keep it in the same box with each > running one. Heck, buy two spares. > I'm not sure that's a valid approach.. because eventually, the spares fail, or there's some crippling problem (year 2000 problems hardcoded in something, etc) At JPL, we are somewhat cursed by the fact that we don't depreciate our test equipment and computers. It's expensed in the year you buy it, and then it is essentially free forever (subject to calibration and maintenance costs). Therefore we have a lot of really old equipment around, and new systems are designed and built incorporating the old equipment. But when the last unit of that old model fails, now you have to update everything and jump multiple generations at one time, which is difficult. You've got a lot of learned history and designs that rely on idiosyncracies of a particular model (e.g. the 8663A, which happens to do phase continuous sweeping and can be phase modulated directly). And now, your venerable 8663 fails. The new replacement model (e.g. the E8663B) is functionally quite similar, has all the same specs (maybe even better in some cases), but, oops, it doesn't do phase continuous sweeping (because the synthesis chain is different). Rather than figure out how to solve the need with the newer gear, this leads to a scrounge fest. You get the institutional inventory and surplus list out and start calling up people who have seem to have another 8663A that hopefully they're not using and/or that it actually works. We've got stacks of dead 8663s sitting around, in, I think, the forlorn hope that someone will be able to cannibalize them for repair parts. The problem is even worse with PCs, because the support cycle time is shorter. The wailing, gnashing of teeth, and pulling of hair when NT 4.0 and later WinXP was declared OS non grata was amazing. Data acquisition systems, lab controllers, etc. all running WinXP and connected to the network as part of their function. Upgrading your software from NT to WinXP to Vista then to 7 then to 8 isn't as painful as jumping from NT to 8. Linux isn't a whole lot better. If you have a system you cobbled together in 2004 that was tied, say, to the typical audio system of the time, odds are that you're in for a real challenge to drop it into a modern distro with modern motherboard hardware. Which version of glibc? OSS audio? parallel port drivers? Oh, your new mobo doesn't HAVE a parallel printer port?
P
Paul
Thu, Dec 11, 2014 3:04 PM

On Thu, Dec 11, 2014 at 9:45 AM, Chris Albertson albertson.chris@gmail.com
wrote:

Your logic would disqualify EVERY computer made today.  What will still be
in production in 10 years?

The ones you make yourself.  Or if you're a nation-state the ones you have
made to your specifications which include N years of support, or the ones
you make yourself.
Most time-nuts are hobbyists who will buy used gear or repurpose things.
That's not a commercial/governmental profile.

On Thu, Dec 11, 2014 at 9:45 AM, Chris Albertson <albertson.chris@gmail.com> wrote: > Your logic would disqualify EVERY computer made today. What will still be > in production in 10 years? > The ones you make yourself. Or if you're a nation-state the ones you have made to your specifications which include N years of support, or the ones you make yourself. Most time-nuts are hobbyists who will buy used gear or repurpose things. That's not a commercial/governmental profile.
DD
Dan Drown
Thu, Dec 11, 2014 3:27 PM

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 albertson.chris@gmail.com:

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


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.

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 <albertson.chris@gmail.com>: > 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 > _______________________________________________ > 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. >
JL
Jim Lux
Thu, Dec 11, 2014 3:33 PM

On 12/11/14, 7:04 AM, Paul wrote:

On Thu, Dec 11, 2014 at 9:45 AM, Chris Albertson albertson.chris@gmail.com
wrote:

Your logic would disqualify EVERY computer made today.  What will still be
in production in 10 years?

The ones you make yourself.  Or if you're a nation-state the ones you have
made to your specifications which include N years of support, or the ones
you make yourself.
Most time-nuts are hobbyists who will buy used gear or repurpose things.
That's not a commercial/governmental profile.

Most national labs are more like time-nuts hobbyists for many of the
same reasons.

A big business (think cellphone provider) depreciates and amortizes
their gear, so they cycle through in 3-5 years, and build the update
process into the budget
. They also buy in large quantities.

National labs are like hobbyists: they buy things and expense them in
the year purchased and use them until they fall apart. They have a
succession of independent projects which come into existence, then go
away, generally without any provision for "sustaining engineering". The
research is done, the report published, move on. They're doing things in
small volumes and repurposing is a way of life.

The "support" is "original builder". And as long as it keeps working,
things are great.  When it stops working, then you're hoping
a) the original builder is still working or alive
b) that you have a charge number to use

Much like a hobbyist.  The Z3801 GPSDO in the garage will probably run
for a good long time. If my daughter needed the 10 MHz output for a
personal project (unlikely, she's a molec bio person) and it failed her
options would be:
a) Hope I'm alive and interested in fixing it. There's no substantive
documentation on the power supply I used (surplus, of course) or the
cabling (bare molex pin shoved into the connector on the Z3801) or the
RS422-RS232 mod (jumpers inside the box).
b) Hope her budget allows buying a replacement and adapting to the
replacement, or finding someone willing to fix it.

Even for things done in the context of a big mission, there's typically
no mechanism for continuing support.  You built a nice phase noise test
setup to characterize the oscillators for a space radio that's getting
put into a Mars rover.  You've finished the oscillators and delivered
them to the next higher level of integration. Your budget ends. Your
test set gets put in a closet, left on a bench, passed on to another
project, but whatever the case, there's no funding to improve, maintain,
modify, update, etc.

On 12/11/14, 7:04 AM, Paul wrote: > On Thu, Dec 11, 2014 at 9:45 AM, Chris Albertson <albertson.chris@gmail.com> > wrote: > >> Your logic would disqualify EVERY computer made today. What will still be >> in production in 10 years? >> > > > The ones you make yourself. Or if you're a nation-state the ones you have > made to your specifications which include N years of support, or the ones > you make yourself. > Most time-nuts are hobbyists who will buy used gear or repurpose things. > That's not a commercial/governmental profile. Most national labs are more like time-nuts hobbyists for many of the same reasons. A big business (think cellphone provider) depreciates and amortizes their gear, so they cycle through in 3-5 years, and *build the update process into the budget*. They also buy in large quantities. National labs are like hobbyists: they buy things and expense them in the year purchased and use them until they fall apart. They have a succession of independent projects which come into existence, then go away, generally without any provision for "sustaining engineering". The research is done, the report published, move on. They're doing things in small volumes and repurposing is a way of life. The "support" is "original builder". And as long as it keeps working, things are great. When it stops working, then you're hoping a) the original builder is still working or alive b) that you have a charge number to use Much like a hobbyist. The Z3801 GPSDO in the garage will probably run for a good long time. If my daughter needed the 10 MHz output for a personal project (unlikely, she's a molec bio person) and it failed her options would be: a) Hope I'm alive and interested in fixing it. There's no substantive documentation on the power supply I used (surplus, of course) or the cabling (bare molex pin shoved into the connector on the Z3801) or the RS422-RS232 mod (jumpers inside the box). b) Hope her budget allows buying a replacement and adapting to the replacement, or finding someone willing to fix it. Even for things done in the context of a big mission, there's typically no mechanism for continuing support. You built a nice phase noise test setup to characterize the oscillators for a space radio that's getting put into a Mars rover. You've finished the oscillators and delivered them to the next higher level of integration. Your budget ends. Your test set gets put in a closet, left on a bench, passed on to another project, but whatever the case, there's no funding to improve, maintain, modify, update, etc.
P
Paul
Thu, Dec 11, 2014 3:35 PM

On Thu, Dec 11, 2014 at 9:59 AM, Jim Lux jimlux@earthlink.net wrote:

Linux isn't a whole lot better. If you have a system you cobbled together
in 2004

In the PPS via GPIO this is an issue and you don't have to go back 10
years.  There's been a major change  between (I think) 3.8 and later
kernels which makes some things much easier but breaks other things.

To be clear my comments aren't about

complex and subtle $10k lab instruments.  They're specifically about 'my
two year old BBB doesn't work like my new one'.  NTP servers are readily
done as a real appliance.  Not a stripped down OS of choice box that is
hosting NTPD that someone calls an 'appliance'.

On Thu, Dec 11, 2014 at 9:59 AM, Jim Lux <jimlux@earthlink.net> wrote: > Linux isn't a whole lot better. If you have a system you cobbled together > in 2004 > In the PPS via GPIO this is an issue and you don't have to go back 10 years. There's been a major change between (I think) 3.8 and later kernels which makes some things much easier but breaks other things. To be clear my comments aren't about complex and subtle $10k lab instruments. They're specifically about 'my two year old BBB doesn't work like my new one'. NTP servers are readily done as a real appliance. Not a stripped down OS of choice box that is hosting NTPD that someone calls an 'appliance'.