Embedded Linux NTP system -500 drift - NTP

This is a discussion on Embedded Linux NTP system -500 drift - NTP ; I'm using a Linux based firewall with a built-in NTP server AND client. My conf file is basic (settings are restricted by the GUI on the device): FILE:/etc/config/ntp.conf MODE:644 ID:0,0 server 192.43.244.18 server 64.236.96.53 server 129.6.15.29 server 129.6.15.28 driftfile /etc/config/ntp.drift ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Embedded Linux NTP system -500 drift

  1. Embedded Linux NTP system -500 drift

    I'm using a Linux based firewall with a built-in NTP server AND
    client. My conf file is basic (settings are restricted by the GUI on
    the device):

    FILE:/etc/config/ntp.conf MODE:644 ID:0,0
    server 192.43.244.18
    server 64.236.96.53
    server 129.6.15.29
    server 129.6.15.28
    driftfile /etc/config/ntp.drift
    pidfile /var/run/ntpd.pid

    I have clients successfully connect to this firewall and sync their
    time... but the device itself (for the past few weeks) has -500 in the
    ntp.drift file. I've tried deleting the ntp.drift file and it gets
    recreated but always ends up at -500. Could the firewall have a bad
    clock chip, does that question even make sense :-)

    Thanks for any ideas! The firewall manufacturer wasn't able to help
    much.

    Cliff.


  2. Re: Embedded Linux NTP system -500 drift

    Cliff wrote:
    > I'm using a Linux based firewall with a built-in NTP server AND
    > client. My conf file is basic (settings are restricted by the GUI on
    > the device):
    >
    > FILE:/etc/config/ntp.conf MODE:644 ID:0,0
    > server 192.43.244.18
    > server 64.236.96.53
    > server 129.6.15.29
    > server 129.6.15.28
    > driftfile /etc/config/ntp.drift
    > pidfile /var/run/ntpd.pid
    >
    > I have clients successfully connect to this firewall and sync their
    > time... but the device itself (for the past few weeks) has -500 in the
    > ntp.drift file. I've tried deleting the ntp.drift file and it gets
    > recreated but always ends up at -500. Could the firewall have a bad
    > clock chip, does that question even make sense :-)
    >
    > Thanks for any ideas! The firewall manufacturer wasn't able to help
    > much.
    >
    > Cliff.
    >


    SOMEBODY has a really bad clock. My guess would be the firewall.

    If the vendor gives you no satisfaction, perhaps you should post the
    details: Vendor name, model, etc.

    For timekeeping purposes, I'd suggest using one of your computers as a
    timeserver and letting the firewall be only a firewall.


  3. Re: Embedded Linux NTP system -500 drift

    Cliff,

    I recommend you check out the "Troubleshooting..." pages at:

    http://ntp.isc.org/Support

    If you are *losing* time, I suspect you have an HZ issue. You might also
    have problems with APCI or ACPI, or DMA interrupts.

    All of these possibilities and more are described on the Support page.

    H

  4. Re: Embedded Linux NTP system -500 drift

    Harlan Stenn wrote:

    > If you are *losing* time, I suspect you have an HZ issue. You might
    > also have problems with APCI or ACPI, or DMA interrupts.


    I think you meant *APIC* (Advanced Programmable Interrupt Controller) or
    ACPI (Advanced Configuration and Power Interface).

  5. Re: Embedded Linux NTP system -500 drift

    Cliff wrote:
    > I'm using a Linux based firewall with a built-in NTP server AND
    > client. My conf file is basic (settings are restricted by the GUI on
    > the device):
    >
    > FILE:/etc/config/ntp.conf MODE:644 ID:0,0
    > server 192.43.244.18
    > server 64.236.96.53
    > server 129.6.15.29
    > server 129.6.15.28



    Append iburst to the end of each of these server lines for faster startup.

    > driftfile /etc/config/ntp.drift
    > pidfile /var/run/ntpd.pid
    >
    > I have clients successfully connect to this firewall and sync their
    > time... but the device itself (for the past few weeks) has -500 in the
    > ntp.drift file. I've tried deleting the ntp.drift file and it gets
    > recreated but always ends up at -500. Could the firewall have a bad
    > clock chip, does that question even make sense :-)
    >


    Are you restarting ntpd after you delete the file? Yes you could have a
    bad clock chip too? What does ntpq -p tell you? Is it receiving packets
    from the servers? Is the firewall set up to receive the packets from the
    servers? 123/UDP needs to be open on the Internet side.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: Embedded Linux NTP system -500 drift

    Thanks for the pointers. I will withold mentioning the device
    manufacturer for the time being as technical support has been helpful
    and they have reproduced the problem but they still have no idea what
    is wrong. Further, I have completely reproduced this issue on an
    identical but separate device. I am now using a single stratum 1
    server, 64.236.96.53 to eliminate as many variables as possible.

    The device does not include debugging utilities such as ntpq or
    ntptrace so it makes it a little more difficult to test (I have
    actually suggested that these commands get included in their firmware
    update).

    Here is the ntp.drift file when ssh into the firewall:

    Sash command shell (version 1.1.1)
    /> cat /etc/config/ntp.drift
    -500.000
    />

    Here is 'ntpq -pn' from an external client to the firewall NTP server
    (after recent restart, so poll is low):

    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    *66.229.xxx.xxx 64.236.96.53 2 u 34 64 377 41.939 -2.830 2.130
    127.127.1.0 LOCAL(0) 10 l 27 64 377 0.000 0.000 0.001

    Here is 'ntptrace' from external client to the firewall:

    localhost: stratum 3, offset -0.005504, synch distance 0.063529
    c-66-229-xxx-xxx.hsd1.fl.comcast.net: stratum 2, offset -0.023189,
    synch distance 0.035368
    64.236.96.53: stratum 1, offset 0.000000, synch distance 0.002650,
    refid 'ACTS'

    I'd appreciate any further assistance. Harlan mentions an HZ problem.
    Not sure what that is. Is that Hz as in Hertz?

    Thanks!


  7. Re: Embedded Linux NTP system -500 drift

    Cliff wrote:
    > Thanks for the pointers. I will withold mentioning the device
    > manufacturer for the time being as technical support has been helpful
    > and they have reproduced the problem but they still have no idea what
    > is wrong. Further, I have completely reproduced this issue on an
    > identical but separate device. I am now using a single stratum 1
    > server, 64.236.96.53 to eliminate as many variables as possible.
    >
    > The device does not include debugging utilities such as ntpq or
    > ntptrace so it makes it a little more difficult to test (I have
    > actually suggested that these commands get included in their firmware
    > update).
    >
    > Here is the ntp.drift file when ssh into the firewall:
    >
    > Sash command shell (version 1.1.1)
    > /> cat /etc/config/ntp.drift
    > -500.000
    > />
    >
    > Here is 'ntpq -pn' from an external client to the firewall NTP server
    > (after recent restart, so poll is low):
    >
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > *66.229.xxx.xxx 64.236.96.53 2 u 34 64 377 41.939 -2.830 2.130
    > 127.127.1.0 LOCAL(0) 10 l 27 64 377 0.000 0.000 0.001
    >
    > Here is 'ntptrace' from external client to the firewall:
    >
    > localhost: stratum 3, offset -0.005504, synch distance 0.063529
    > c-66-229-xxx-xxx.hsd1.fl.comcast.net: stratum 2, offset -0.023189,
    > synch distance 0.035368
    > 64.236.96.53: stratum 1, offset 0.000000, synch distance 0.002650,
    > refid 'ACTS'
    >
    > I'd appreciate any further assistance. Harlan mentions an HZ problem.
    > Not sure what that is. Is that Hz as in Hertz?
    >
    > Thanks!
    >


    "HZ" is a Linux Kernel parameter that can be set to values such as 100,
    250 or 1000. It controls the rate at which the clock is updated. If HZ
    is set to values greater than 100 it is possible for Linux to lose clock
    interrupts if something masks or disables interrupts for too long a
    time. I don't know if this is a consideration in embedded Linux or not.
    If ntpd is having problems staying synchronized and HZ is greater than
    100, try setting it to 100.


+ Reply to Thread