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 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)
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
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.
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 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 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.
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.
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 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'.