[ntp:questions] Re: "Proper" way to test simple, new NTP configuration?

Richard B. Gilbert rgilbert88 at comcast.net
Fri May 20 20:59:59 UTC 2005


ohaya wrote:

>"Richard B. Gilbert" wrote:
>  
>
>>ohaya wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I'm trying to setup NTP on a small network consisting of all Sun Solaris
>>>systems.
>>>
>>>I'm appending a post that I just made to the Sun admin NG about our
>>>configuration, but after doing more reading, I'm wondering if maybe the
>>>problem was 'how' we did the test.
>>>
>>>As mentioned below, to test this, after getting all of the xntpd's up, I
>>>simply set the clock back on Solaris1, then watched.  Since making the
>>>post, I've found a couple of msgs that seem to indicate that maybe I
>>>should have killed the xntpd on Solaris1 (our NTP "server"), then set
>>>the time back on that system, then restart the xntpd.
>>>
>>>Can someone here comment on this?  What is the best (and easiest way) to
>>>determine if this simple NTP setup is actually working?
>>>
>>>Thanks,
>>>Jim
>>>
>>>
>>>================= Post about our configuration
>>>==========================
>>>Hi,
>>>
>>>I have a very small network consisting of 4 Solaris servers (Solaris1,
>>>..., Solaris4) and want to configure NTP so that Solaris2, Solaris3, and
>>>Solaris4 synch their time to Solaris1.
>>>
>>>This is an isolated network (no outside connection available), so from
>>>what I've read, I think that Solaris1 should be synched to itself?
>>>
>>>We tried to set this up yesterday, and got the xnptd running on all 4
>>>machines, but when we tested, it didn't seem that anything was happening
>>>(we ran snoops on port 123 on several of the machines).
>>>
>>>We tested by first using ntpdate on Solaris2, 3, and 4 to get them
>>>synched to Solaris1, then starting the xnptd on those machines, then
>>>setting the system clock on Solaris1 back about 10 minutes, and then
>>>watching the snoop output for awhile.
>>>
>>>Can someone provide what the basic ntp.conf file should look like for
>>>Solaris1 and for the other Solaris machines (Solaris2, 3, and 4)?
>>>
>>>Thanks,
>>>
>>>
>>>      
>>>
>>Don't expect too much from this configuration!!!   A typical,
>>undisciplined, computer clock is not a good synchronization source.
>>
>>The  machine that keeps the best time by itself; e.g. the clock that
>>gains or loses the least amount of time, should be selected as the master.
>>
>>On the master, /etc/ntp.conf should contain the statements
>>#
>># Declare the local clock to be the clock of last resort.
>># It will be used to serve time in the absence of any other.
>>#
>>server 127.127.1.0              # Local clock, unit 0
>>fudge 127.127.1.0 stratum 10
>>
>>On the clients, /etc/ntp.conf  should include:
>>server <ip address of server>
>>
>>As I said, don't expect too much.   The server will drift and the
>>clients will follow it as best they can.  (Imagine following a drunk
>>driver!)
>>
>>If you want something that both keeps the correct time and keeps tight
>>synchronization, get a hardware reference clock for your server.   A GPS
>>timing receiver is generally the best choice if you can site the antenna
>>where it has an unobstructed view of the sky.  These can generally be
>>had for less than $500 US, a lot less if you get the bare bones (naked
>>circuit board, wall wart, hockey puck antenna)!  If not, HF receivers
>>for WWV, WWVH, CHU, JJY etc can be used.  VLF receivers (WWVB, MSF, or
>>DCF77, etc) are also an option.
>>    
>>
>
>
>Richard,
>
>Thanks for the information, esp. the configuration.
>
>FYI, not "expecting much", this configuration is fine for what I am
>doing.  The main reason why I wanted to implement this in our test
>network is that we are testing some SSO software, which requires that
>all the servers be synchronized time-wise within a certain amount of
>time.  For this, the absolute time (vs. "the real clock time") is not
>important, so this is ok for us.  In our 'real' production environment,
>they've already deployed a framework for synching machine times, but up
>to now, I was having to manually do the synching in our development
>network.
>
>Jim
>  
>
You should be able to keep synchronization within, say, 50 milliseconds 
with no problem.  With a stable reference clock 5 ms is easy and 500 
microseconds or better is possible.



More information about the questions mailing list