[time-nuts] NIST time services

Chris Albertson albertson.chris at gmail.com
Mon Mar 24 04:51:12 UTC 2014


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 at rubidium.dyndns.org> wrote:

> Jason,
>
> On 23/03/14 17:26, Jason Rabel wrote:
>
>> NTP is best used over the Internet. It was designed for unreliable data
>>> links.
>>>
>>
>> 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.
>>
>
> 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
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at 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



More information about the Time-nuts_lists.febo.com mailing list