In the quest for expansion of NTP over the internet, one thing has always nagged me.

You can find lists of servers and they will give a physical location along with other info about them...

Big whoop... Often these servers tend to be tied to one backbone, so even if they are physically located in the same city as me, the
packets still might have to travel thousands of miles just to switch networks. So what should be a 2ms delay has now become 20-40ms
(or more)... Even if they have multiple backbones, packets coming in are not guaranteed to leave on the same network. The more a
packet has to travel, the more uncertainty you build up... Yes NTP should still get you a reasonable time, but our quest is always
for something better.

If there was some sort of feature in NTP (maybe there already is???), or even a separate program that could "test" a list of NTP
servers to try and pick the lowest latency, I think that could have a positive benefit on better time transfer.

Hi

You can (and many do) run through a list of servers with an NTP client and see what you get. It’s a bit of work, but you only do it once.

———

I suspect that what NIST is looking for is somebody in the cloud business (Amazon, Google, Microsoft, IBM) to step up and mention that they have 2,989,875 server racks scattered about the world and they would be happy to run NTP on them for “free”. (see fine print attached ….)

Bob

On Mar 23, 2014, at 12:26 PM, Jason Rabel jason@extremeoverclocking.com wrote:

On Sun, Mar 23, 2014 at 9:26 AM, Jason Rabel
jason@extremeoverclocking.com wrote:

Yes.  This is exactly how NTP works.  It constantly tests the servers
and selects the "best" subset of available reference clocks. This will
changes over time and it will change in real time.

There is a rather complex algorithm.  First the set of clocks is
thinned down to what the code calls "true tickers", those are the
clocks the generally agree with the rest of the clocks.  Then from
the clocks who are not "voted off the island" so to speak the time is
computed using a kind of weighting.

The assumption NTP makes is that  you can judge the quality of a
server by the variance (of "jitter") in the time it reports.

So yes, the problem the problem and the solution you thought of was
build into NTP about 30 years ago.  It fact that is the whole point of
it's being, to estimate the variance in round trip point times and use
this to determine how much to weight the results.  NOW, the key
assumption NTP makes might be wrong and this is a large source of
error.  It assumes the one-way jitter is 1/2 the round trip jitter.
If this is wrong it would give incorrect weight to a server.

NTP will eventually settle on the best few servers it finds but
continues to talk to all of them just because which are the "best"
will change over time.

A good example of this is a stratum 1 server that has a GPS connected.
Almost certainly it will also connect to other NTP servers and get
time from them as well as the GPS.  Very quickly it will determine
that the GPS has the "best" performance and will use that.  But if you
disconnect the GPS antenna it will very quickly find the next best
source(s) of time.

Another example is an "island network".  Say you have five NTP servers
that are interconnected so that they each get time from the other
four.  Normally they also use some Internet servers but when the
Internet goes down NTP will find which of the local island servers has
the most stable clock and those will cary the most weight in the
calculation of "consensus time" which is a weighted time based on all
"true tickers".

--

Chris Albertson
Redondo Beach, California

On Sun, Mar 23, 2014 at 1:08 PM, Bob Camp lists@rtty.us wrote:

There's no mention of compensation in the solicitation for input however
they do want some things that might or might not fit the business models of
the large server companies:
-) Traceable time.
0) 180 day hold-over in the absence of GPS (presumably with less than a
microsend error).

1. Dedicated (low-latency) links to the UTC(NIST) ensemble
2. Notable oversight by NIST.
3. Geo dispersion.

Point three may seem a no-brainer but it disqualifies Amazon if they're
using only native infrastructure.  It sounds like they want what they
should have gotten from Certichron/USTiming but didn't.

I suspect the best candidates would be someone like Hurricane or Equinix
with the Level3s in the second tier.

Jason,

On 23/03/14 17:26, Jason Rabel wrote:

This hits straight into one of the problems with NTP. It tries to use
the highest stratum clock rather than best quality clock. A known trick
is to use a set of stratum 2 servers locally and only let local users
connect to those, and them have them peer between each other and to the
same stratum 1 clocks. This gives much better performance then letting
the clients to use the stratum 1 servers directly.

The hop-count is good to avoid routing loops, but it is not a good
indicator of achieved quality.

If we have decent intermediary, this would provide much better
performance. As fewer would query the top servers, the second level
could query them much more often, and better filter the result for the
benefit of performance.

But that would break the basic assumptions of NTP, and you can't do
that, not that the protocol would object.

Your general idea is however sound, and surely you can do stuff with
scripts.

Cheers,
Magnus

On 3/23/14 10:48 AM, Paul wrote:

An RFI isn't a solicitation (an offer to buy).  It's more the
equivalent of mailing away for everyone's sales literature.  If costs
are mentioned in someone's response, that might help NIST figure out
their cost/benefit and make vs buy analyses.  For most RFIs, the
responses are public.

however

Or, they might be looking for someone to be a system integrator, and put
it all together.  That's what an RFI is all about.. get the ideas from
people who have them, so that when the solicitation does come out,
they're looking to buy something that someone is willing to sell.

It might also help them figure out what kind of budget they will need.

Note well that you don't have to be a provider of services to respond to
the RFI.  If you have good ideas, but aren't able to implement them, for
whatever reason (maybe you personally don't want to be running a
business), you can still send them to NIST, and they'll factor into
their decision making and planning process.

When I've been involved in issuing RFIs in the past, often the best
ideas come from people/firms who aren't in the business.  The folks in
the business are often loathe to publicly put their ideas out there,
because they fear it will telegraph information to their competitors
about future business plans.  If you're not planning on competing, what
do you care who knows about your ideas.

It's not really stratum based.  The clock selection algorithm is described
here
http://www.eecis.udel.edu/~mills/ntp/html/select.html
Basically it "allows every clock that can logically contribute"  That means
with estimated error bounds that over lap.

That with those not eliminated nTP applies a clustering algorithm to find
the set of clocks that will contribute to the weighted average time
http://www.eecis.udel.edu/~mills/ntp/html/cluster.html

The weight is not based on Stratum but it might turn out that many time it
looks like it does simply because the servers using GPS or atomic clocks
are very stable and get weighted up.  The weight is  1/(root distance)
where root distance is computed from offset and jitter.

Do NOT look at the "billboard" display.  It would have you think NTP picks
just one clock.  It rarely does that.

The bottom line is that when setting up NTP you want to get it many clocks
and let it pick.  You might even get it two GPS receivers or GPS and a Rb
derived PPS and then five pool servers as backup.

On Sun, Mar 23, 2014 at 5:07 PM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:

--

Chris Albertson
Redondo Beach, California