Xntp d'ont slow the clock on alphaserver with Tru64 - NTP

This is a discussion on Xntp d'ont slow the clock on alphaserver with Tru64 - NTP ; Hi, I have configured an alphaserver with tru64 v5.1b to be NTP (ntpq 4.1.1 Fri Apr 29 14:25:45 EDT 2005) client, its configuration file is: # cat /etc/ntp.conf server 127.127.1.0 fudge 127.127.1.0 stratum 10 driftfile /var/ntp/drift multicastclient 224.0.1.1 broadcastdelay 0.008 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Xntp d'ont slow the clock on alphaserver with Tru64

  1. Xntp d'ont slow the clock on alphaserver with Tru64

    Hi,

    I have configured an alphaserver with tru64 v5.1b to be NTP (ntpq
    4.1.1 Fri Apr 29 14:25:45 EDT 2005) client, its configuration file is:
    # cat /etc/ntp.conf
    server 127.127.1.0
    fudge 127.127.1.0 stratum 10
    driftfile /var/ntp/drift
    multicastclient 224.0.1.1
    broadcastdelay 0.008
    authenticate no

    This alphaserver synchronise its clock thanks to two stratum 2 NTP
    server connected on the same subnet.
    ntpq> peer
    remote refid st t when poll reach delay
    offset jitter
    ================================================== ============================
    LOCAL(0) LOCAL(0) 10 l 58 64 377 0.000
    0.000 0.488
    +serv1 ntpclock-lan 2 - 32 64 377 0.488 -67.351
    1.347
    *serv2 ntpclock-lan 2 - 16 64 377 0.488 -67.501
    1.570

    It seems that xntpd never slow the clock and a step is done as soon as
    the offset is under -128ms.
    daemon.log:Mar 14 07:58:27 xntpd[362529]: ntpd 4.1.1 Fri Apr 29
    16:10:01 EDT 2005
    daemon.log:Mar 14 07:58:27 xntpd[362529]: precision = 976 usec
    daemon.log:Mar 14 07:58:27 xntpd[362529]: kernel time discipline
    status 0040
    daemon.log:Mar 14 07:58:27 xntpd[362529]: frequency initialized 0.000
    from /var/ntp/drift

    The file /var/ntp/drift always contain 0.000. Reset and lost
    synchronisation are observed every 2 hours.

    Using logfile option in /etc/ntp.conf I can also see this message
    14 Mar 08:05:50 xntpd[362529]: get_kernel_info: ntp_adjtime() failed:
    Function not implemented
    14 Mar 08:17:41 xntpd[362529]: time reset -0.149086 s
    14 Mar 08:17:41 xntpd[362529]: system event 'event_clock_reset' (0x05)
    status 'leap_none, sync_unspec, 5 events, event_peer/strat_chg' (0x54)
    14 Mar 08:17:41 xntpd[362529]: system event 'event_peer/
    strat_chg' (0x04) status 'leap_none, sync_unspec, 6 events,
    event_clock_reset' (0x65)

    Is there someone to help me with this problem?

    Regards

    Steph.

  2. Re: Xntp d'ont slow the clock on alphaserver with Tru64

    I see 2 possible problems:

    > daemon.log:Mar 14 07:58:27 xntpd[362529]: frequency initialized 0.000
    > from /var/ntp/drift


    I would delete your driftfile after stopping (x)ntpd and
    before restarting it. As it is, you are telling NTP to start with
    a known drift rate of 0, and it will take a long(er) time to
    compute an accurate rate. You are using a non-standard path
    for that file on Tru64, so also make sure the ownership and
    permissions are correct for the subdirectories you are using.
    Each should be owned and writeable by root.

    This may also be part of your problem:

    > 14 Mar 08:05:50 xntpd[362529]: get_kernel_info: ntp_adjtime() failed:
    > Function not implemented


    I note that your version of ntp is a little old, so you might want
    to update your patches, but I think the proximate cause of this
    message is that your (x)ntpd image is trying to use the kernel time
    discipline system call, but you have not enabled that in your kernel.

    For the Tru64 kernel time discipline, /sys/conf/[SYSTEMNAME] should
    contain the line:

    options NTP_TIME

    If not, you can run "doconfig", making sure to include the NTP option
    from the menu, or you can manually edit /sys/conf/[SYSTEMNAME]
    to add the needed line and then run "doconfig -c [SYSTEMNAME]".
    Both of these will build a new kernel containing the missing
    routine.

    -Tom

    Stephane Guillou wrote:
    > Hi,
    >
    > I have configured an alphaserver with tru64 v5.1b to be NTP (ntpq
    > 4.1.1 Fri Apr 29 14:25:45 EDT 2005) client, its configuration file is:
    > # cat /etc/ntp.conf
    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 10
    > driftfile /var/ntp/drift
    > multicastclient 224.0.1.1
    > broadcastdelay 0.008
    > authenticate no
    >
    > This alphaserver synchronise its clock thanks to two stratum 2 NTP
    > server connected on the same subnet.
    > ntpq> peer
    > remote refid st t when poll reach delay
    > offset jitter
    > ================================================== ============================
    > LOCAL(0) LOCAL(0) 10 l 58 64 377 0.000
    > 0.000 0.488
    > +serv1 ntpclock-lan 2 - 32 64 377 0.488 -67.351
    > 1.347
    > *serv2 ntpclock-lan 2 - 16 64 377 0.488 -67.501
    > 1.570
    >
    > It seems that xntpd never slow the clock and a step is done as soon as
    > the offset is under -128ms.
    > daemon.log:Mar 14 07:58:27 xntpd[362529]: ntpd 4.1.1 Fri Apr 29
    > 16:10:01 EDT 2005
    > daemon.log:Mar 14 07:58:27 xntpd[362529]: precision = 976 usec
    > daemon.log:Mar 14 07:58:27 xntpd[362529]: kernel time discipline
    > status 0040
    > daemon.log:Mar 14 07:58:27 xntpd[362529]: frequency initialized 0.000
    > from /var/ntp/drift
    >
    > The file /var/ntp/drift always contain 0.000. Reset and lost
    > synchronisation are observed every 2 hours.
    >
    > Using logfile option in /etc/ntp.conf I can also see this message
    > 14 Mar 08:05:50 xntpd[362529]: get_kernel_info: ntp_adjtime() failed:
    > Function not implemented
    > 14 Mar 08:17:41 xntpd[362529]: time reset -0.149086 s
    > 14 Mar 08:17:41 xntpd[362529]: system event 'event_clock_reset' (0x05)
    > status 'leap_none, sync_unspec, 5 events, event_peer/strat_chg' (0x54)
    > 14 Mar 08:17:41 xntpd[362529]: system event 'event_peer/
    > strat_chg' (0x04) status 'leap_none, sync_unspec, 6 events,
    > event_clock_reset' (0x65)
    >
    > Is there someone to help me with this problem?
    >
    > Regards
    >
    > Steph.


+ Reply to Thread