I tried setting ophan mode.

on 192.168.0.5  I put

tos orphan 6

at the end of the ntp.conf file

on 192.168.0.4 I ran ntpdate to set the clock

I got this

[shackle@galactica-304 ~]$ sudo ntpdate -d 192.168.0.5
1 Aug 10:31:02 ntpdate[18776]: ntpdate 4.2.6p3-RC10@1.2239-o Thu Nov 25 16:18:33 UTC 2010 (1)
Looking for host 192.168.0.5 and service ntp
host found : 192.168.0.5
transmit(192.168.0.5)
receive(192.168.0.5)
transmit(192.168.0.5)
receive(192.168.0.5)
transmit(192.168.0.5)
receive(192.168.0.5)
transmit(192.168.0.5)
receive(192.168.0.5)
192.168.0.5: Server dropped: Server has gone too long without sync
server 192.168.0.5, port 123
stratum 6, precision -23, leap 00, trust 000
refid [192.168.0.5], delay 0.02597, dispersion 0.00002
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: d3c3bca8.ef07b5bb  Wed, Aug  1 2012 10:33:12.933
transmit timestamp:  d3c3bc2c.7c88ab05  Wed, Aug  1 2012 10:31:08.486
filter delay:  0.02597  0.02600  0.02597  0.02605
         0.00000  0.00000  0.00000  0.00000
filter offset: 124.4469 124.4469 124.4469 124.4469
         0.000000 0.000000 0.000000 0.000000
delay 0.02597, dispersion 0.00002
offset 124.446969

1 Aug 10:31:08 ntpdate[18776]: no server suitable for synchronization found
[shackle@galactica-304 ~]$


It prints the right time and stratum but still stubbornly won't set the time.


If I add
server 192.168.0.5

to the ntp.conf on 192.168.0.4 and restart the ntp server on 192.168.0.4

there are no errors logged but I also see no improvement in the offset between the two
systems after waiting a few minutes.

-- Will



On 07/31/2012 12:06 PM, unruh wrote:
One option is to install a gps receiver onto one or more of your
machines to deliver accurate time to them.

The second option is to look into "orphan" mode, which was designed for
your situation.

Your problem is probably that you are using more than one of th
emachines as the "server" and they have gotten out of sync with each
otehr so that the other machines cannot figure out which is the more
accurate time. You give no indication of what you have set up so it is
pretty hard to figure out what is going wrong.

On 2012-07-30, Will Shackleford<shac...@nist.gov>  wrote:
We have several computers  with several different operating systems on a
local network with no radios and no internet connection.
The main goal is to keep them synchronized with each other.

One frustration I have had is that clients tend to refuse to connect to
servers on the network
that are "not good enough". I assume "not good enough" means too high a
stratum although the
stratum does not really matter (unless it is 15 or so) but disagreement
amongst the servers does matter.

error messages are not that clear.
Perhaps if you told us what they were, they would be clearer to some of
us than to you.

My current solution is to take a laptop to another room with an internet
connection, let it sit for an hour and
then bring it back to connect the local network where finally the other
computers will accept it and synchronize with it.


Questions:

How can I configure a client/peer to always accept a server as "good
enough" or atleast always accept the server
when no other server can be contacted? (please answer for any platform
below you can)


Fedora 6:
Fedora 10:
Fedora 14:
Ubuntu 11.04:
Windows XP:


How can I configure a server to always consider itself "good enough" and
report that (lie if necessary) so that any badly configured
client will still connect?(please answer for any platform below you can)


Fedora 6:
Fedora 10:
Fedora 14:
Ubuntu 11.04:
Windows XP:



Just for my own curiosity, why is just refusing to do what the operator
wants the default behavior for clients/peers? Why not always
synchronize as well as you can with whichever peers/hosts you can contact?
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

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

Reply via email to