Linux as clients not synching with Win/Tardis Time server

Linux as clients not synching with Win/Tardis Time server

Post by suj » Fri, 07 Dec 2007 02:05:53


Windows NTP server = Win 2003 Std Ed, Win 2000, Win 2003 Std Ed SP2
64 bit Linux= Suse SLES 2.6.16.21-0.8
NTP version = XXXX@XXXXX.COM

The 3 windows NTP time servers are pointing to the external public
time server pool.
I looked up your archives and I see references to modifying W32time /
Windows registry and ofcourse advice to make Linux the time servers.
Our setup has 3 windows servers with Tardis2000 running as the time
server to our windows clients. We are deploying linux servers and want
to maintain status quo on the time servers till we reach a critical
mass where eventually we will have linux as NTP servers. So for the
time being we have to sync up Linux clients with Win Time Servers.
I have setup the ntp.conf as per the standard
my ntp.conf:
------------------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server <Win NTp Server-1 IP> burst iburst
server <Win NTp Server-2 IP> burst iburst
server <Win NTp Server-3 IP> burst iburst

peer <linux-server2-ip>
peer <linux-server2-ip>
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
------------------
austinpower:/home/austin # ntpdc -c peers
remote local st poll reach delay
offset disp
===================================================
*LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000
0.03033
=10.248.0.22 10.248.3.231 14 1024 377 0.00017 -69.55465
0.06303
=gargoyle1.abc 10.248.3.231 14 1024 377 0.00015 -70.18628
0.06310
=gargoyle2.abc 10.248.3.231 14 1024 377 0.00017 -69.14703 0.06311

The 3 Win time servers have a stratum of 14 and the Linux time is
synched to its LCL clock. Also the ntpd does not like the time servers
as seen from the "x" against their entries

austinpower:/home/austin # ntpq -p
remote refid st t when poll reach
delay offset jitter
==============================================================
*LOCAL(0) LOCAL(0) 10 l 23 64 377 0.000
0.000 0.001
xgargoyle1.abc 216.bb.68.yyy 14 u 232 1024 377 0.153 -70186.
1.645
xgargoyle2.abc 216.bb.68.xxx 14 u 348 1024 377 0.179 -69147.
5.233
x10.222.0.55 71.bb.xx.xx 14 u 726 1024 377 0.170 -69554.
2.765

giving the time server IP in the ntpq command;
# ntpq -p 10.248.0.xxx
10.248.0.xxx: timed out, nothing received
***Request timed out

I have Linux bonding/network teaming, should that make a difference to
the ntp syncing?
I don't think so, but just explaining the setup.

austinpower:/home/austin # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
10.248.3.0 0.0.0.0 255.255.255.0 U 0
0 0 bond0
127.0.0.0 0.0.0.0 255.0.0.0 U 0
0 0 lo
0.0.0.0 10.222.3.254 0.0.0.0 UG 0
0 0 bond0

ntpdate command exits as if the time servers were not available. But I
can ping those Win servers from my linux servers, basically not a
network connectivity issue. I can also do a "nslookup <WinNTPserverIP>
" from the linux m/c's and it resolves the names correctly.

ntpdate cmd comes back with ;
# ntpdate -u
5 Dec 10:39:05 ntpdate[10238]: no servers can be used, exiting

# ntpdate -u gargoyle1.abcd.com
5 Dec 10:39:27 ntpdate[10239]: no server suitable for synchronization
found

#cat /var/lib/ntp/drift/ntp
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by David J Ta » Fri, 07 Dec 2007 02:30:29


[]

Why not run NTP on the Windows PCs?

Cheers,
David

 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by suj » Fri, 07 Dec 2007 03:43:00

We are planning on eventually getting Linux to be the NTP servers, but
since the existing clients are all pointing to the Win server with
Tardis on it, we want to maintain it that way till we migrate to linux
completely. The concern is to get the linux servers to right now be
able to point to the existing Win servers with Tardis.
Suj

On Dec 5, 12:30 pm, "David J Taylor" < XXXX@XXXXX.COM
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by David J Ta » Fri, 07 Dec 2007 03:51:37


Your choice, of course. You might save yourself time installing NTP via a
good install.

Cheers,
David
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by maye » Tue, 11 Dec 2007 08:17:57


Don't. Just have the Linux servers point to external servers like the
pool and then you don't have to change anything later. You are likely to
get better quality time service that way. Tardis is a bit short on
technical information so it's hard to tell what it does, how it does it
and how reliable the service is.

Danny
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by eugenemi » Tue, 11 Dec 2007 09:33:05

n Dec 5, 11:05 am, suj < XXXX@XXXXX.COM > wrote:

Isn't there a problem here with the stratum levels? Tardis on the
Windows boxes is set to stratum 14, and the local clock on the Linux
box is fudged to stratum 10. A stratum 10 is not going to sync to a
stratum 14.

Genek
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by hal-usene » Tue, 11 Dec 2007 09:42:53


I thought that name rang a bell..

http://www.yqcomputer.com/ #Tardis_and_Trinity_College.2C_Dublin

The seem to be short on clues as well as technical information.

--
These are my opinions, not necessarily my employer's. I hate spam.
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by Steve Kost » Tue, 11 Dec 2007 10:04:27


Please trim the quoted material in your reply.

http://www.yqcomputer.com/


The linux systems should not be using the Undisciplined Local Clock
unless they are serving time to others _and_ they need to be able to do
so even when no real time sources are reachable.

--
Steve Kostecke < XXXX@XXXXX.COM >
NTP Public Services Project - http://www.yqcomputer.com/
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by Richard B. » Tue, 11 Dec 2007 11:06:01


<snip>

Why are you using both the burst and iburst keywords?

Iburst is used to get a fast startup by sending the first eight requests
at intervals of two seconds. This fills the filter pipeline and gets
enough data to start synchronizing the clock in six *** seconds. It is
recommended for normal use.

Burst, OTOH, is a special purpose hack intended for systems that make a
dialup telephone connection one to three times per day. It causes your
system to send eight queries at interals of two seconds at each poll
interval. You should NOT be using it unless you have the permission of
the server's owner since it places eight times the normal load on the
server. Even if YOU own the servers, it's not going to do you much good
unless, as mentioned above, you are making a dialup connection at long
intervals.

The NTP documentation does not explain this as well as it might! It is,
however, much improved since I first saw it four or five years ago!
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by maye » Tue, 11 Dec 2007 11:38:58


My knowledge of Tardis actually goes back to the mid-1990's when I was
pursuing something else. I did not get much information back then
either. I know about that incident too and we did get them to change the
way he was doing things.

Danny
 
 
 

Linux as clients not synching with Win/Tardis Time server

Post by suj » Wed, 12 Dec 2007 02:18:17

Danny:>Don't. Just have the Linux servers point to external servers
like the
Suj: That is an option but the mgmt wants as few open ports on the
prod linux servers as possible. So I want to leave this as the last
option.
Suj: I agree with Danny the setup on Tardis leaves very few option to
play with.
And like Eugene said all my windows/Tardis time servers do have
stratum 14 as seen from the 'ntpq -p' cmd

Richard:> Why are you using both the burst and iburst keywords?
Suj: I have taken out the burst and left the servers only with the
iburst
I have also set up the other linux servers as peers so they can synch
up with their peers, they all have stratum 11
# ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 55 64 377 0.000
0.000 0.001
xgargoyle1.abc 67.159.5.52 14 u 84 256 377 0.156 12704.3
328.239
xgargoyle2.abc 67.159.5.52 14 u 139 256 377 0.247 12832.0
267.283
xgargoyle3.abc 63.240.161.99 14 u 84 256 377 0.167 12005.3
668.244
x10.2.3.4 LOCAL(0) 11 u 9 256 377 4.198
16908.0 92.224
x10.2.3.5 LOCAL(0) 11 u 24 256 377 0.144
-286201 481.533

the gargoyle's are win time server with Tardis on them.
------------------------
We had a power outage and when the server came up after the outage the
clock on my server went ahead by 2 hours and I manually set it back,
but within 15min it went ahead by another 2 hours again?

Qt) Should my hardware clock be set to UTC or localtime with ntp? I
have setup the hwclock to "localtime " with the Eastern Time Zone. Is
that responsible for the erratic clock behaviour? Shd I set it to UTC
and set it to EST zone?
my /sbin/hwclock --debug shows

# /sbin/hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1193781221 seconds after 1969
Last calibration done at 1193781221 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2007/12/10 13:33:52
Hw clock time : 2007/12/10 13:33:52 = 1197311632 seconds since 1969
Mon 10 Dec 2007 01:33:52 PM EST -0.705158 seconds

# date
Mon Dec 10 11:33:48 EST 2007

a Difference of (13.33.52) -( 11.33.48) = 2hr

# hwclock
Mon 10 Dec 2007 01:33:52 PM EST -0.705158 seconds