Different NTP options on peers

[Timothe Litt]

On 16-Feb-16 11:15, dhcp-users-request at lists.isc.org wrote:
> Message: 5
> Date: Tue, 16 Feb 2016 16:15:36 +0000
> From: "Stier, Matthew" <Matthew.Stier at us.fujitsu.com>
> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> Subject: RE: Different NTP options on peers
> Message-ID:
> 	<430FB7087F60DD4FB40A1408F257458BD7D729ED at RCHEXMBP1.fnc.net.local>
> Content-Type: text/plain; charset="utf-8"
>
> No need.  The NTP client will query all available NTP services and choose one to follow.  This query/choose continues as long as the client is running, so it knows it is getting the best time source available.  As the time service stabilize, the NTP client will slowly increase the time period between queries, to reduce the load on the NTP servers.  If there is a disruption, the client will simply reset to a short time period, and when thing settle down again, it will again, slowly increase the time period between queries.
This is true if your clients are NTP.  If they're Windoze clients (using
win32 time) they just ask the first one. 

They don't do any of the NTP sync algorithms.  They just ask, use what
they get, and some long time later, ask again.

There are lots of more accurate ways to manage time.  But windows
doesn't care - as long as you can sync with your kerberos tokens, it's
happy.  That needs maybe 5 mins accuracy; win32time can't do better than
a few seconds.  If you really care about time (or you want your
makefiles/source control repos to run on a shared disk in an active
development environment), you can get a real NTP client for windows, but
almost no one does.

SNTP is midway between the two. 

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4994 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20160216/9cfe44a5/attachment.bin>