Ben Rockwood wrote:
> I've read in the past that clients should always have an
>  odd-number of NTP servers;

(Shrug)
 I don't think any "ODD" quantity matters much;
  However more (within reason),
   and diverse (although perhaps not far away),
  have value.

e.g. tos minsane 4 minclock 6 cohort 1


> 1 server or 3 servers but not 2.  If I recall the reason
> was that clients could become "confused" and needs a tie breaker.

That depends on what those two servers are responding with.

 Both might be selected as candidate for synchronization,
  one of them designated as the system peer,
  and their combined offsets used.

 One might be selected as the system peer, and the other rejected.

 Both might be rejected.


> Question 1: I want to challenge this old assumption.
> Is there truth to it?

<http://www.eecis.udel.edu/~mills/ntp/html/warp.html> How NTP Works
<http://www.eecis.udel.edu/~mills/ntp/html/select.html> Clock Select Algorithm
<http://www.eecis.udel.edu/~mills/ntp/html/cluster.html> Clock Cluster Algorithm


> In many environments there is a desire to have 2 NTP servers for
> redundancy purposes, but not 3 due to limited resources.

What resource limitations?

 Equipment Cost?
  It costs next to nothing to use your existing equipment.

  Many piece of network equipment could also be a LAN NTP Client/Server,
   enterprise routers, web servers, ftp servers, database servers,
   application servers, print servers, ...

  You could also make any network client a e.g. ManyCastClient/Server.

   NTPd uses a negligible amount of system resources.


 Bandwidth Cost?
  If you use GPS, CDMA, LORAN, WWV, MSF, DCF77 , ...
   there is no bandwidth cost.
    ... and if e.g. internet access goes down,
         you still have the reference clocks.


Most would likely use a combination of some kind of radio clocks,
 NTP peers at other corporate facilities,
 and/or NTP servers on the internet (Upstream ISP ?).

 Resulting in several local (LAN) NTP servers that use
  their reference clocks, each other, and a couple of remote servers.

 Local (LAN) clients then sync to those several local servers.


> Question 2: Furthermore, if you have 2 local NTP servers
>  is it preferable to have them sync off of different
>  sources to avoid a client syncing servers that are using
>  the same reference clock?  ie: Is this bad?:
>
> $ ntpq -pn
>     remote         refid st t when poll reach delay offset jitter
> =================================================================
> *10.0.91.10 207.171.7.152 3 u  756 1024  377  0.494  0.596  0.352
> +10.0.91.82 207.171.7.152 3 u  953 1024  377  0.135  0.144  0.241

If you have no reference clocks,
 and you only have one server to sync to,
 where does that leave you when that one "207.171.7.152" server
 goes down / is unavailable / can not be reached / ...

Why not have your NTP servers sync
 to a couple different external servers,
 and each other?


e.g. (expanded from your example)

# 10.0.91.10 NTP Server
tos minsane 4 minclock 6 cohort 1 orphan 11
restrict source nomodify
keys "/etc/ntp.keys" # e.g. contains: 123 M YOUR_MD5_KEY
trustedkey 123
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
peer 10.0.91.82 iburst prefer
# server 10.0.91.82 iburst prefer
server timekeeper.delphij.net iburst            # Fremont, CA 
support.ntp.org/bin/view/Servers/TimekeeperDelphijNet
pool clock.fmt.he.net iburst preempt            # Fremont, CA Pool 
he.net/adm/ntp.html
pool clock.develooper.com iburst preempt        # develooper Pool 
support.ntp.org/bin/view/Servers/ClockDevelooperCom (you were already using 
them)
pool us.pool.ntp.org iburst preempt             # NTP.org country pool 
www.pool.ntp.org/zone/us
pool time.bldrdoc.gov iburst preempt minpoll 10 # NIST Pool 
nist.gov/pml/div688/grp40/its.cfm


# 10.0.91.82 NTP Server
tos minsane 4 minclock 6 cohort 1 orphan 11
restrict source nomodify
keys "/etc/ntp.keys" # e.g. contains: 123 M YOUR_MD5_KEY
trustedkey 123
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
peer 10.0.91.10 iburst prefer
# server 10.0.91.10 iburst prefer
server time.envirahost.com iburst               # Fremont, CA 
support.ntp.org/bin/view/Servers/TimeXenscaleCom
pool clock.fmt.he.net iburst preempt            # Fremont, CA Pool 
he.net/adm/ntp.html
pool clock.develooper.com iburst preempt        # develooper Pool 
support.ntp.org/bin/view/Servers/ClockDevelooperCom (you were already using 
them)
pool us.pool.ntp.org iburst preempt             # NTP.org country pool 
www.pool.ntp.org/zone/us
pool time.bldrdoc.gov iburst preempt minpoll 10 # NIST Pool 
nist.gov/pml/div688/grp40/its.cfm


# NTP Clients
tos cohort 1
restrict source nomodify
keys "/etc/ntp.keys" # e.g. contains: 123 M YOUR_MD5_KEY
trustedkey 123
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
multicastclient 224.0.1.1 key 123 preempt
broadcastclient


-- 
E-Mail Sent to this address <blackl...@anitech-systems.com>
  will be added to the BlackLists.

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to