Linux as clients not synching with Win/Tardis Time server - NTP

This is a discussion on Linux as clients not synching with Win/Tardis Time server - NTP ; 3 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 =4.2.0a@1.1196-r The 3 windows NTP time servers are pointing to the external public time server pool. ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Linux as clients not synching with Win/Tardis Time server

  1. Linux as clients not synching with Win/Tardis Time server

    3 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 =4.2.0a@1.1196-r

    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 burst iburst
    server burst iburst
    server burst iburst

    peer
    peer
    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
    " 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.drift
    -143.940 result on one linux server
    460.786 result on the other linux server

    # netstat -anu
    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address Foreign Address
    State
    udp 0 0 255.255.255.255:427
    0.0.0.0:*
    udp 0 0 10.abc.yy.32:123 0.0.0.0:* <<<
    Secondary bond IP
    udp 0 0 10.abc.yy.31:123 0.0.0.0:* <<< Secondary
    bond IP
    udp 0 0 10.abc.yy.30:123 0.0.0.0:* <<< Secondary
    bond IP
    udp 0 0 10.abc.yy.130:123 0.0.0.0:* <<< Primary
    bond IP
    udp 0 0 127.0.0.1:123
    0.0.0.0:*
    udp 0 0 0.0.0.0:123
    0.0.0.0:*
    udp 0 0 :::
    123 :::*

    How can I make these linux servers to sync up with the tardis time
    servers on the windoze boxes?
    Thanking in advance.
    Suj

  2. Re: Linux as clients not synching with Win/Tardis Time server

    suj wrote:
    []
    > How can I make these linux servers to sync up with the tardis time
    > servers on the windows boxes?
    > Thanking in advance.
    > Suj


    Why not run NTP on the Windows PCs?

    Cheers,
    David



  3. Re: Linux as clients not synching with Win/Tardis Time server

    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" bit.nor-this-bit.co.uk> wrote:

    >
    > Why not run NTP on the Windows PCs?
    >
    > Cheers,
    > David



  4. Re: Linux as clients not synching with Win/Tardis Time server

    suj wrote:
    > 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


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

    Cheers,
    David



  5. Re: Linux as clients not synching with Win/TardisTime server

    suj wrote:
    > 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
    >


    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

  6. Re: Linux as clients not synching with Win/Tardis Time server

    On Dec 5, 11:05 am, suj wrote:
    > 3 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 =4.2...@1.1196-r
    >
    > 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 burst iburst
    > server burst iburst
    > server burst iburst
    >
    > peer
    > peer
    > 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
    > " 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.drift
    > -143.940 result on one linux server
    > 460.786 result on the other linux server
    >
    > # netstat -anu
    > Active Internet connections (servers and established)
    > Proto Recv-Q Send-Q Local Address Foreign Address
    > State
    > udp 0 0 255.255.255.255:427
    > 0.0.0.0:*
    > udp 0 0 10.abc.yy.32:123 0.0.0.0:* <<<
    > Secondary bond IP
    > udp 0 0 10.abc.yy.31:123 0.0.0.0:* <<< Secondary
    > bond IP
    > udp 0 0 10.abc.yy.30:123 0.0.0.0:* <<< Secondary
    > bond IP
    > udp 0 0 10.abc.yy.130:123 0.0.0.0:* <<< Primary
    > bond IP
    > udp 0 0 127.0.0.1:123
    > 0.0.0.0:*
    > udp 0 0 0.0.0.0:123
    > 0.0.0.0:*
    > udp 0 0 :::
    > 123 :::*
    >
    > How can I make these linux servers to sync up with the tardis time
    > servers on the windoze boxes?
    > Thanking in advance.
    > Suj


    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

  7. Re: Linux as clients not synching with Win/Tardis Time server


    >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.


    I thought that name rang a bell..

    http://en.wikipedia.org/wiki/NTP_ser...lege.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.


  8. Re: Linux as clients not synching with Win/Tardis Time server

    On 2007-12-10, eugenemil@sbcglobal.net wrote:

    > On Dec 5, 11:05 am, suj wrote:
    >
    > [---=| Quote block shrinked by t-prot: 108 lines snipped |=---]


    Please trim the quoted material in your reply.

    http://www.netmeister.org/news/learn2quote.html

    >> How can I make these linux servers to sync up with the tardis time
    >> servers on the windoze boxes?

    >
    > 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.


    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
    NTP Public Services Project - http://support.ntp.org/

  9. Re: Linux as clients not synching with Win/Tardis Time server

    suj wrote:
    > 3 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 =4.2.0a@1.1196-r
    >
    > 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 burst iburst
    > server burst iburst
    > server burst iburst
    >



    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 sixteen 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!





  10. Re: Linux as clients not synching with Win/TardisTime server

    Hal Murray wrote:
    >> 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.

    >
    > I thought that name rang a bell..
    >
    > http://en.wikipedia.org/wiki/NTP_ser...lege.2C_Dublin
    >
    > The seem to be short on clues as well as technical information.
    >


    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

  11. Re: Linux as clients not synching with Win/Tardis Time server

    Danny:>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.

    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

+ Reply to Thread