Synchronizing using servers in stratum 1 and 2

Synchronizing using servers in stratum 1 and 2

Post by Timo Ruite » Tue, 13 Feb 2007 00:18:46


Hi all,

When using pool.ntp.org the DNS randomly select time servers. Since
stratum-1 servers and stratum-2 servers share the same pool you will get
a mix of them when using 0.nl.pool.ntp.org, 1.nl.pool.ntp.org, and
2.nl.pool.ntp.org for instance.
When you are assigned *one* stratum-1 server and *two* stratum-2 servers
your clock will obviously synchronize to the stratum-1 server. But that
being the case, what is the use of the two stratum-2 servers, assuming
that the stratum-1 server will not go off-line?
Could it be so that if the stratum-1 server is not so accurate after all
it would still be selected over the stratum-2 servers (since no
reference stratum-1 server is available)?
Will you not be better served instead when you are assigned *three*
stratum-2 servers, so the selection process of ntpd will compare all
three servers equally and choose the best one, switching to another if
that one looks more stable after a while?


Regards,
Timo
 
 
 

Synchronizing using servers in stratum 1 and 2

Post by davi » Tue, 13 Feb 2007 02:57:53

In article <45cf33d4$0$321$ XXXX@XXXXX.COM >,



It will synchronize to a mixture of the times from all three servers, but
weighted in favour of the stratum 1 one, I believe. Although it only
reports one server as reference source, it actually makes use of timing
information from several of them.


They can outvote the stratum one server if it is giving the wrong time.
Note that some people reckon that you need four servers for this to
work reliably.

 
 
 

Synchronizing using servers in stratum 1 and 2

Post by stephe » Tue, 13 Feb 2007 03:04:01

In article <45cf33d4$0$321$ XXXX@XXXXX.COM > Timo Ruiter < XXXX@XXXXX.COM > writes:
$When you are assigned *one* stratum-1 server and *two* stratum-2 servers
$your clock will obviously synchronize to the stratum-1 server.

Often, but not always. If (for instance) the delays between you and
the stratum 1 server are severe or tend to bounce around a lot, you
may find that you synchronize to one of the stratum 2 servers instead.
I've noticed over the years that ntpd seems to have a fairly strong
preference for stratum, but not so strong that it won't choose
(say) a stratum 3 or 4 server over a stratum 2 server if the former
seems better behaved than the latter.

$ But that
$being the case, what is the use of the two stratum-2 servers, assuming
$that the stratum-1 server will not go off-line?

That's another good use of them: it is a poor assumption that a
given server will never go offline. Sooner or later, *every* server
goes offline.

You seem to be forgetting a couple of points about pool.ntp.org.
One is that it is not intended to provide you with the absolute best
time synchronization possible. It maintains a pool of servers, checks
to make sure each one is reasonably accurate, and knows nothing about
what the network paths between you and any of those servers might be.
If you have a critical need for highly precise time synchronization,
pool.ntp.org is not for you, as pointed out on the pool's Web site;
you should choose servers manually, picking those which are highly
accurate and close (in a network sense) to you, or you should hook
your computer up to a hardware time source (perhaps something like a
GPS device). If you just want to keep your clock's accuracy to within
a fraction of a second, the pool should be good enough.

The other is that the goal of the project is to try to spread
the load reasonably evenly among participating servers. That was,
in fact, the very reason for the pool's creation in the first place.
If the pool were to track stratum and bias the pool towards using
stratum 1 servers, those servers would experience heavy loads, and
their owners would probably react by taking them out of the pool.
That wouldn't benefit anyone.

I manage three servers in the pool. They usually hang out within
a few tens of milliseconds of The One True Time, according to both the
pool's monitoring system and the output of ntpq -p. They're almost
always stratum 3, as the servers used by them are typically at
stratum 2. I realize that there are cases in which a machine might
need a server with higher accuracy than that, but probably >99.99%
of the machines hooked up to the Internet don't need anything better.
--
Stephen M. Dunn < XXXX@XXXXX.COM >
------------------------------------------------------------------
Say hi to my cat -- http://www.yqcomputer.com/
 
 
 

Synchronizing using servers in stratum 1 and 2

Post by Timo Ruite » Thu, 15 Feb 2007 04:04:49

David Woolley schreef:

Can anyone confirm this?
 
 
 

Synchronizing using servers in stratum 1 and 2

Post by davi » Thu, 15 Feb 2007 07:50:44

In article <45d20bd0$0$329$ XXXX@XXXXX.COM >,


For NTPV3, using the PDF version (although I think that the IETF is
right in requiring plain text standards), see pages 84 and 85. The
weighting is the reciprocal of an error term plus the maximum possible
value of that times the stratum, so for large stratums it is essentially
inverse stratum and, for stratum one, inverse error term. The error
term is distance (peer). Using more than the first choice is optional.
Curioulsy, it's in an appendix.

For the actual implementation of NTPV4 in version 4.2.0 of the reference
implementation it is weighted by reciprocal root distance, but doesn't
seem to include the stratum.

/*
* clock_combine - combine offsets from selected peers
*/
static double
clock_combine(
struct peer **peers,
int npeers
)
{
int i;
double x, y, z;

y = z = 0;
for (i = 0; i < npeers; i++) {
x = root_distance(peers[i]);
y += 1. / x;
z += peers[i]->offset / x;
}
return (z / y);
}
/*
* root_distance - compute synchronization distance from peer to root
*/
static double
root_distance(
struct peer *peer
)
{
/*
* Careful squeak here. The value returned must be greater than
* zero blamed on the peer jitter, which must be at least the
* square of sys_precision.
*/
return ((peer->rootdelay + peer->delay) / 2 +
peer->rootdispersion + peer->disp + clock_phi *
(current_time - peer->update) + SQRT(peer->jitter));
}
 
 
 

Synchronizing using servers in stratum 1 and 2

Post by Timo Ruite » Fri, 16 Feb 2007 03:25:06

Timo Ruiter schreef:
What I really wanted to know is what is better in terms of stability:
*one* stratum-1 server and *two* stratum-2 servers versus *three*
stratum-2 servers.
When having only one stratum-1 server available you might be relying on
that server too much; when having three stratum-2 servers (ideally
synchronized to three different stratum-1 servers) time *could* be more
stable since there are three stratum-1 servers involved, albeit through
the stratum-2 servers.

This is a pure theoretical issue as far as I'm concerned, since who can
tell the difference if your servers are 23 milliseconds off...
So replace "stratum-1" by "stratum-N" and "stratum-2" by
"stratum-(N-1)"; the question will remain the same.

Regards,
Timo
 
 
 

Synchronizing using servers in stratum 1 and 2

Post by Richard B. » Fri, 16 Feb 2007 04:18:03


Think first about adding another server! Three servers can degenerate
too easily to the two server case! When those two servers disagree. . . .