Drift from serial activity, VIA system, LInux - NTP

This is a discussion on Drift from serial activity, VIA system, LInux - NTP ; I'm setting up a small system to monitor things like line voltage and temperature. It uses a serial connection to a UPS box to get the line voltage. The quirk is that the drift changes when I run the monitoring ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Drift from serial activity, VIA system, LInux

  1. Drift from serial activity, VIA system, LInux

    I'm setting up a small system to monitor things like line voltage
    and temperature.

    It uses a serial connection to a UPS box to get the line voltage.

    The quirk is that the drift changes when I run the monitoring
    program. It changes more if I poll faster. It changed by
    20 ppm when I was polling with a 10 ms delay and it's more
    than 80 ppm and still climbing when I reduced the delay to 1 ms.

    I let it run for a few days in the 20 ppm mode. The drift was stable,
    just like it was before I turned on the monitoring code. I can see
    it track the daily temperature changes.


    The system is a VIA C7 CPU with a VT3314 chipset running
    a 2.6.25 kernel. The kernel sources are stock but the
    configuration options are my own.

    Has anybody seen anything like this? Any suggestions on where
    I should look for more info and/or to track this down?


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


  2. Re: Drift from serial activity, VIA system, LInux

    Hal Murray wrote:

    > The quirk is that the drift changes when I run the monitoring
    > program. It changes more if I poll faster. It changed by
    > 20 ppm when I was polling with a 10 ms delay and it's more
    > than 80 ppm and still climbing when I reduced the delay to 1 ms.



    My first guess would be a bug in the tickless clock in some recent
    Linuxes. If possible, disable this and see if it improves things. If
    it does take it up with the Linux kernel developers (I think this one
    came from Red Hat), but let us know as well, as this is something that
    was introduced without consulting the NTP community.

    Note that tickless clock processing also led to some unofficial changes
    in ntpd, in Linux, which again are the responsibility of the Linux
    developers.

    Note, to operate with 1ms delays in a non-tickless system, you need a
    1000Hz clock and that is vulnerable to lost interrupts from slow device
    drivers.

    I'm assuming that the UPS monitoring program runs in user space,
    otherwise it could be causing lost interrupts, itself.

  3. Re: Drift from serial activity, VIA system, LInux

    In article <484ba1f1$0$661$5a6aecb4@news.aaisp.net.uk>,
    David Woolley writes:
    >Hal Murray wrote:
    >
    >> The quirk is that the drift changes when I run the monitoring
    >> program. It changes more if I poll faster. It changed by
    >> 20 ppm when I was polling with a 10 ms delay and it's more
    >> than 80 ppm and still climbing when I reduced the delay to 1 ms.

    >
    >
    >My first guess would be a bug in the tickless clock in some recent
    >Linuxes. If possible, disable this and see if it improves things. If
    >it does take it up with the Linux kernel developers (I think this one
    >came from Red Hat), but let us know as well, as this is something that
    >was introduced without consulting the NTP community.


    Interesting suggestion. Thanks.

    Something changes when I turn off the tickless stuff in the kernel.
    I haven't sorted out what's going on yet.


    >Note that tickless clock processing also led to some unofficial changes
    >in ntpd, in Linux, which again are the responsibility of the Linux
    >developers.


    I'm using a recent ntp-dev with no changes from any distribution channels.

    >Note, to operate with 1ms delays in a non-tickless system, you need a
    >1000Hz clock and that is vulnerable to lost interrupts from slow device
    >drivers.


    >I'm assuming that the UPS monitoring program runs in user space,
    >otherwise it could be causing lost interrupts, itself.


    Yes. It's a simple/dumb user program. It pokes a serial port
    a lot and occasionally writes a line to a log file.


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


+ Reply to Thread