I have just set up an NTP server on a Taroon Beta 1 machine. The NTP server seems to be running, but when trying to do an "ntpdate" against it, the client receives the following error:
teapot:~# ntpdate -d glass 1 Aug 17:22:18 ntpdate[7453]: ntpdate 4.1.1c-rc2@1.866 Tue Jul 1 09:35:22 EDT 2003 (1) transmit(192.168.0.2) receive(192.168.0.2) transmit(192.168.0.2) receive(192.168.0.2) transmit(192.168.0.2) receive(192.168.0.2) transmit(192.168.0.2) receive(192.168.0.2) transmit(192.168.0.2) 192.168.0.2: Server dropped: strata too high server 192.168.0.2, port 123 stratum 16, precision -16, leap 11, trust 000 refid [0.0.0.0], delay 0.02579, dispersion 0.00000 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 originate timestamp: c2d5042b.84226809 Fri, Aug 1 2003 17:22:19.516 transmit timestamp: c2d5042a.fa702a34 Fri, Aug 1 2003 17:22:18.978 filter delay: 0.02591 0.02579 0.02579 0.02580 0.00000 0.00000 0.00000 0.00000 filter offset: 0.537794 0.537777 0.537770 0.537781 0.000000 0.000000 0.000000 0.000000 delay 0.02579, dispersion 0.00000 offset 0.537777
1 Aug 17:22:18 ntpdate[7453]: no server suitable for synchronization found
This is my "ntp.conf" file:
driftfile /etc/ntp/data/drift broadcastdelay 0.008 server ntp1.curie.fr server ntp2.curie.fr server ntp3.curie.fr server time.nist.gov server clock.redhat.com
Why does my NTP server assigns itself an stratum of 16, instead of an stratum of 2 (since all the assigned NTP servers have an stratum of 1)?
I'm out of game with this. Thanks!
On Fri, 1 Aug 2003, Felipe Alfaro Solana wrote:
I have just set up an NTP server on a Taroon Beta 1 machine. The NTP server seems to be running, but when trying to do an "ntpdate" against it, the client receives the following error:
Have a look at the server with ntpq. Once you start ntpq run the pe, as, and rv commands and you should get an idea what is going on. It sounds to me like your server is not synced. AN unsynced server is normally strat 16.
On Fri, 2003-08-01 at 18:07, Tom Diehl wrote:
I have just set up an NTP server on a Taroon Beta 1 machine. The NTP server seems to be running, but when trying to do an "ntpdate" against it, the client receives the following error:
Have a look at the server with ntpq. Once you start ntpq run the pe, as, and rv commands and you should get an idea what is going on. It sounds to me like your server is not synced. AN unsynced server is normally strat 16.
The server should be synched, since upon starting "ntpd", the "ntpdate" command is invoked and the time is synched. At least, that's what is seems from looking at "/var/log/messages" and invoking "ntpdate" manually.
NOTE: I have had to modify "/etc/init.d/ntpd" because my firewall is preventing any UDP traffic from privileged (<1023) ports from passing through it. Thus, I've had to add the "-u" option to "ntpdate". Could this be affecting the NTP server? Is there any ntpd option to force usage of non-privileged source UDP ports?
I must say that I have no idea about NTP, so all of this is completely new to me. Here are is the output of "ntpq":
ntpq> pe remote refid st t when poll reach delay offset disp ============================================================================== woon.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 xoon.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 lip.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 time.nist.gov 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 clock.redhat.co 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 44140 8000 yes no 2 44141 8000 yes no 3 44142 8000 yes no 4 44143 8000 yes no 5 44144 8000 yes no ntpq> rv status=c011 sync_alarm, sync_unspec, 1 event, event_restart system="Linux", leap=11, stratum=16, rootdelay=0.00, rootdispersion=0.00, peer=0, refid=0.0.0.0, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, poll=4, clock=c2d51d07.8b3aa000 Fri, Aug 1 2003 19:08:23.543, phase=0.000, freq=0.00, error=0.00
What's really strange is how all the NTP servers from which time is synched are set an stratum of 16. For example, "woon.curie.fr" is really an stratum 1 server:
# ntptrace woon.curie.fr woon.curie.fr: stratum 1, offset 0.211136, synch distance 0.00000, refid 'GPS'
What's going on here? Any ideas? Thanks!
On Fri, 1 Aug 2003, Felipe Alfaro Solana wrote:
On Fri, 2003-08-01 at 18:07, Tom Diehl wrote:
I have just set up an NTP server on a Taroon Beta 1 machine. The NTP server seems to be running, but when trying to do an "ntpdate" against it, the client receives the following error:
Have a look at the server with ntpq. Once you start ntpq run the pe, as, and rv commands and you should get an idea what is going on. It sounds to me like your server is not synced. AN unsynced server is normally strat 16.
The server should be synched, since upon starting "ntpd", the "ntpdate" command is invoked and the time is synched. At least, that's what is seems from looking at "/var/log/messages" and invoking "ntpdate" manually.
NOTE: I have had to modify "/etc/init.d/ntpd" because my firewall is preventing any UDP traffic from privileged (<1023) ports from passing through it. Thus, I've had to add the "-u" option to "ntpdate". Could this be affecting the NTP server? Is there any ntpd option to force usage of non-privileged source UDP ports?
You need port 123 udp open for ntp to function.
I must say that I have no idea about NTP, so all of this is completely new to me. Here are is the output of "ntpq":
ntpq> pe remote refid st t when poll reach delay offset disp ============================================================================== woon.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 xoon.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 lip.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 time.nist.gov 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 clock.redhat.co 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
This indicates that your server is unable to talk to the time servers you wish to sync with. The st column is the stratum of the server. The reach column is the number of seconds since the last time your server got a reply from the server listed.
ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 44140 8000 yes no 2 44141 8000 yes no 3 44142 8000 yes no 4 44143 8000 yes no 5 44144 8000 yes no
this says I cannot find the servers.
ntpq> rv status=c011 sync_alarm, sync_unspec, 1 event, event_restart system="Linux", leap=11, stratum=16, rootdelay=0.00, rootdispersion=0.00, peer=0, refid=0.0.0.0, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, poll=4, clock=c2d51d07.8b3aa000 Fri, Aug 1 2003 19:08:23.543, phase=0.000, freq=0.00, error=0.00
This among other things says your clock is stratum 16
What's really strange is how all the NTP servers from which time is synched are set an stratum of 16. For example, "woon.curie.fr" is really an stratum 1 server:
# ntptrace woon.curie.fr woon.curie.fr: stratum 1, offset 0.211136, synch distance 0.00000, refid 'GPS'
What's going on here? Any ideas? Thanks!
your not talking to the time servers. You MUST be able to talk to the timeservers on port 123 udp otherwise it will not work.
Just for reference here is the pe output from one of my timeservers: (icarus pts8) # ntpq ntpq> pe remote refid st t when poll reach delay offset jitter ============================================================================== +bonehed.lcs.mit .GPS. 1 u 668 1024 377 29.893 10.282 6.852 +NAVOBS1.MIT.EDU .PSC. 1 u 667 1024 377 29.669 10.152 0.075 *time.nist.gov .ACTS. 1 u 696 1024 377 102.528 -2.858 5.146
Now as: ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 26580 9434 yes yes none candidat reachable 3 2 26581 9434 yes yes none candidat reachable 3 3 26582 9634 yes yes none sys.peer reachable 3
Now rv: ntpq> rv status=06b4 leap_none, sync_ntp, 11 events, event_peer/strat_chg, version="ntpd 4.1.1a@1.791 Sat Aug 31 18:27:29 EDT 2002 (1)", processor="i686", system="Linux2.4.20-19.8", leap=00, stratum=2, precision=-17, rootdelay=102.528, rootdispersion=55.574, peer=26582, refid=time.nist.gov, reftime=c2d5211f.ef404ea4 Fri, Aug 1 2003 13:25:51.934, poll=10, clock=c2d5240e.5ae88df3 Fri, Aug 1 2003 13:38:22.355, state=4, offset=2.715, frequency=-130.203, jitter=29.472, stability=0.043
See the difference??
On Fri, 1 Aug 2003, Tom Diehl wrote:
On Fri, 1 Aug 2003, Felipe Alfaro Solana wrote:
On Fri, 2003-08-01 at 18:07, Tom Diehl wrote:
ntpq> pe remote refid st t when poll reach delay offset disp ============================================================================== woon.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 xoon.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 lip.curie.fr 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 time.nist.gov 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0 clock.redhat.co 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
This indicates that your server is unable to talk to the time servers you wish to sync with. The st column is the stratum of the server. The reach column is the number of seconds since the last time your server got a reply from the server listed.
OOPS that is wrong. The when column is the number of seconds since the last reply. Sorry.
Hello Felipe,
The server should be synched, since upon starting "ntpd", the "ntpdate" command is invoked and the time is synched.
ntpd has to sync itself with its peers. The fact that the system clock is synced by ntpdate doesn't matter in that respect.
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
On Fri, 2003-08-01 at 19:51, Tom Diehl wrote:
This indicates that your server is unable to talk to the time servers you wish to sync with. The st column is the stratum of the server. The reach column is the number of seconds since the last time your server got a reply from the server listed.
OOPS that is wrong. The when column is the number of seconds since the last reply. Sorry.
Never mind :-) I have been able to fix it... You were right: I had to open 139/UDP through my firewall to get NTP server synching. Thanks!
On Fri, 2003-08-01 at 20:17, Felipe Alfaro Solana wrote:
Never mind :-) I have been able to fix it... You were right: I had to open 139/UDP through my firewall to get NTP server synching. Thanks!
139 or 123? 139 is used for Windows networking... if you've opened that up you might want to close it again :)
On Sat, 2003-08-02 at 03:33, Kyle Maxwell wrote:
On Fri, 2003-08-01 at 20:17, Felipe Alfaro Solana wrote:
Never mind :-) I have been able to fix it... You were right: I had to open 139/UDP through my firewall to get NTP server synching. Thanks!
139 or 123? 139 is used for Windows networking... if you've opened that up you might want to close it again :)
123/UDP :-)
On Sat, 2 Aug 2003, Leonard den Ottolander wrote:
Hello Felipe,
The server should be synched, since upon starting "ntpd", the "ntpdate" command is invoked and the time is synched.
ntpd has to sync itself with its peers. The fact that the system clock is synced by ntpdate doesn't matter in that respect.
Just so you know, Felipe, this can take as long as 5 minutes. I don't understand the protocol enough to give you anything more deterministic than that. What I believe its doing in this time is trying to determine how much delay it can expect from the network in order to adjust any values it gets from the upstream server for this (and it probably is looking at things like latency internal to the server its on also).
So basically you just have to give it a little time, and eventually it will get synced up. What the nptdate does is at least give it a sane starting point so that the sync can occur, and won't take nearly as long.
Cheers...james
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list