I would, but I don't have the time at the moment :)

Didier KO4BB

On March 19, 2014 12:18:23 AM CDT, Tom Van Baak tvb@LeapSecond.com wrote:

--
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things.

On 3/18/14 10:18 PM, Tom Van Baak wrote:

For those that are unfamiliar with the ways of US Government
contracting, this is NOT a request for proposals to provide the service.
It's more of a preliminary step to identify potential bidders, gather
background information, shake the trees to find out who the potential
players are, as well as help make a decision on whether it's even a good
idea.  (e.g. it might feature into a make vs buy report)

We do this at NASA when we want to make sure we haven't missed something
in the marketplace.  These days, Government folks don't go to as many
conferences and almost no trade shows.  So you find out what's available
by exercising google or bing, which is not such a great way to find
niche products and services.  Someone who's got a great way to do
reliable, accurate time distribution over the internet might not have a
big web presence, or might be overshadowed by something similar that has
been heavily Search Engine Optimized.

This is also a way for people who aren't necessarily interested in
providing the service to give comments to NIST about potential issues
that may be of concern.  Those kinds of comments might wind up changing
the eventual procurement, or might even result in a report that says
"nope, not worth privatizing this, because of reasons A, B, and C".
that's the crux of question 7 at the end "What are advantages and
disadvantages of NIST's potential transition of time services from a
NIST-only service to private sector operation..."

A lot of the questions at the end of the RFI are things that get
discussed on time-nuts from time to time.

So they want to in-invent NTP?

I think NTP already services way more than 6.5 billion per day.  The
problem with NTP is while it is nearly optimal and provides the best
time accuracy for a given hardware/network setup it is not technically
"traceable" even if the time really is from NIST indirectly.

I think you could fix this traceability problem with some rules about
how to write the configuration files, no new software.  For example
NTP already handles cryptographic authentication.  Make the use of
this monitory so that then you know you are talking to a NIST
referenced server.

On Tue, Mar 18, 2014 at 10:18 PM, Tom Van Baak tvb@leapsecond.com wrote:

--

Chris Albertson
Redondo Beach, California

On 3/19/14 9:50 AM, Chris Albertson wrote:

They are well aware of NTP.. they serve 6.5 billion a day from NIST
and that's what they are looking at potentially outsourcing or changing.

And, of course, there's the "legally traceable" aspect.

That's very possible, and you could respond to the RFI and tell them so.
Could you set up a legally traceable set of multiple tiers?
What would the mechanics of this be?

That's really what the RFI is all about.. "tell us what you think we
need to know"..

They'll get responses that are overlapping existing knowledge, for sure.

And nobody is going to respond with something that is confidential or
proprietary or telegraphs a future product line, because all the RFI
responses are essentially public info.

I can see a use for an inexpensive GPSDO with a built-in
gigabit ethernet or USB3  port powering an NTP server.

On 03/19/2014 10:21 AM, Jim Lux wrote:

--
Chuck Forsberg WA7KGX  caf@omen.com  www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc      "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231  503-614-0430

On Sat, Mar 22, 2014 at 12:24 PM, Chuck Forsberg WA7KGX caf@omen.com wrote:

Neither of those is a good way to transfer time to an NTP server.
Both Ethernet and USB are packetized.  The best way is with a simple
wire with a square wave pulse on it that pulses ones per second.
Nothing can be more simple or accurate.

The trick is to build an NTP server that can react deterministically
to the pulse.  I think an ARM based system could far outperform an
Intel based one.  ARM has two independent PRUs.  These are little
32-bit processes each with 4K of memory that are build right on the
same chip as the main ARM CPU.  The PRUs purpose built for real time
task and can handle nanosecond level timing.  In most existing system
the PRUs are ignored and everything is done using the ARM.

The other way to improve things even better is to not even bother to
have a link from the GPSDO to the NTP server.  Why not simply run the
NTP server software on the same processor as the GPSDO?  Just one of
the little PRUs is more than powerful enough to run a GPSDO.  They are
a 32-bit uP that runs at 200MHz, one instruction per clock.  The PRUs
don't run any operating system code but have access to all of the
ARM's memory and interrupts.  A PRU is way-overkill for a GPSDO.
Doing this eliminates the link cable from the GPSDO to the NTP server.
If the ARM CPU can't handle 6 billion requests per day then buy many
copies the ARM based systems.  They are cheap.

--

Chris Albertson
Redondo Beach, California

On Sat, Mar 22, 2014 at 2:24 PM, Chuck Forsberg WA7KGX caf@omen.com wrote:

Why not a BeagleBoneBlack with a GPS module that has 1pps out connected to
an I/O pin. For that matter, add your OCXO and let the BBB discipline that
at the same time.

I bet you can come up with an NTP server and a GPSDO for not more than $200.

--
Brian Lloyd, WB6RQN/J79BPL
706 Flightline Drive
Spring Branch, TX 78070
brian@lloyd.com
+1.916.877.5067

The PRUs (Programmable Realtime Unit) aren't a feature of ARM in general
(they are not present
on the Raspberry Pi for instance).  The BeagleBone has 2 PRUs as you
describe.  It uses the TI Siatra
ARM variant.
ARM just describes the core architecture.  Manufacturers tack on all
sorts of proprietary peripherals
depending on what they envision as it's primary target market.

Mike George

On 3/22/2014 15:54, Chris Albertson wrote:

On Sat, Mar 22, 2014 at 4:16 PM, Brian Lloyd brian@lloyd.com wrote:

I believe the Laureline largely meets the spec.  It all "open" -- hardware
and software.
It's not gigE but it was suggested you could swap in a 1588 PHY.
The downside is it's fake NTP so some of the interesting bits won't work
but those shouldn't concern the time-nut.