Best solution for millisecond accuracy - NTP

This is a discussion on Best solution for millisecond accuracy - NTP ; Hi, I am running several (less than 30) servers on LAN with these restrictions : - no Internet - Windows XP/2003 - no GPS possible - I need less than a millisecond accuracy. 5 of them are on the same ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Best solution for millisecond accuracy

  1. Best solution for millisecond accuracy

    Hi,

    I am running several (less than 30) servers on LAN with these restrictions :
    - no Internet
    - Windows XP/2003
    - no GPS possible
    - I need less than a millisecond accuracy.

    5 of them are on the same switch and two in an other building. Latency
    between buildings is less than 20ms. There _might_ be an internal NTP
    server synchronised to a server on internet but let say i dont have to
    count on it.

    If :
    - i choose one "good" server as my time reference (local clock) and
    synchronised all the other clients to it

    - i put all servers in peer mode

    - i put a pci card that uses a TCXO to replace the hardware clock (any
    known vendors ? i dont care about GPS sync)

    - limit maxpoll (what is the impact ?)

    - change OS (again what is the impact ?)

    is the accuracy of a millisecond "achievable" in those conditions ? If
    not, what can i do to achieve it ?
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: Best solution for millisecond accuracy

    edouard funke wrote:
    > Hi,
    >
    > I am running several (less than 30) servers on LAN with these restrictions :
    > - no Internet
    > - Windows XP/2003
    > - no GPS possible
    > - I need less than a millisecond accuracy.


    That wording is a little ambiguous. I'll assume that you mean the error
    must be less than 1 millisecond.

    >
    > 5 of them are on the same switch and two in an other building. Latency
    > between buildings is less than 20ms. There _might_ be an internal NTP
    > server synchronised to a server on internet but let say i dont have to
    > count on it.
    >
    > If :
    > - i choose one "good" server as my time reference (local clock) and
    > synchronised all the other clients to it
    >
    > - i put all servers in peer mode
    >
    > - i put a pci card that uses a TCXO to replace the hardware clock (any
    > known vendors ? i dont care about GPS sync)


    Symmetricomm and Meinberg both offer such products. The GPS is optional
    with Symmetricomm (BC637PCI is PCI card with built-in GPS and BC635PCI
    is without GPS). I believe an OCXO is optional with one or both of the
    Symmetricomm products. I was quoted a little less that $1100 US for the
    Meinberg product. I think Symmetriccom is more expensive. (They make
    good stuff but charge top dollar for it!)

    >
    > - limit maxpoll (what is the impact ?)

    The correct polling interval for the circumstances will be selected by
    ntpd. Don't change the defaults unless you understand the NTP algorithms!

    >
    > - change OS (again what is the impact ?)

    Some operating systems keep time a little better than others. Windows
    and Linux have both been known to lose clock interrupts during periods
    of high disk usage. I've had good results with Solaris (8, 9, & 10) but
    others here seem to have had results differing from mine!

    >
    > is the accuracy of a millisecond "achievable" in those conditions ? If
    > not, what can i do to achieve it ?


    No! There is no way that I know of that you can set a clock to within
    one millisecond unless you have an NTP server that has the time correct
    to within less than a millisecond. Plus or minus one second is about
    the best you can hope for if you set the time by hand.

    Without a UTC reference (hardware reference clock or at least one (four
    or more are best practice) internet server) your clocks WILL drift.
    They may drift badly. Synchronization between systems may be fairly
    loose (many milliseconds difference between different machines).

    The 20 millisecond network delay between buildings seems excessive and
    may cause problems. The maximum error in transmitting time from server
    to client is one half of the round trip delay. The actual error may be,
    and usually is, far less than one half the delay but there is no guarantee.

    GPS is the least expensive sort of hardware reference clock. A Garmin
    GPS18LVC may be purchased for around $85 US. You will need to provide a
    5VDC power supply and a connector (DB25 or DB9 as appropriate) to
    connect it to a serial port. Some soldering is required. You will also
    need to be able to site an antenna with an unobstructed view of the sky.


  3. Re: Best solution for millisecond accuracy

    In article <46043069.1010200@comcast.net>,
    Richard B. gilbert wrote:
    > edouard funke wrote:


    > > - change OS (again what is the impact ?)

    > Some operating systems keep time a little better than others. Windows
    > and Linux have both been known to lose clock interrupts during periods
    > of high disk usage. I've had good results with Solaris (8, 9, & 10) but
    > others here seem to have had results differing from mine!


    Also, Windows, in default configuration, will only provide a resolution
    of about 15 to 20ms (whatever the clock interrupt rate is) in the times
    provided to application programs. ntpd plays tricks to make its own times
    more accurate, and therefore the phase of the system clock more accurate,
    but, in my experience, that breaks down when the system is heavily loaded.

    It is possible that enabling multimedia timers will improve the resolution
    of time supplied to application programs; I haven't tested this. However,
    I would think that the probability of lost interrupts will be increased. It's
    absolutely essential that you do not change the enablement state of these
    timers, as the transition causes a shift in the time seen by ntpd.

    > > is the accuracy of a millisecond "achievable" in those conditions ? If
    > > not, what can i do to achieve it ?


    > Without a UTC reference (hardware reference clock or at least one (four
    > or more are best practice) internet server) your clocks WILL drift.
    > They may drift badly. Synchronization between systems may be fairly
    > loose (many milliseconds difference between different machines).


    I imagine he is only concerned about the synchronisation between machines.
    Especially with a TXCO, that should be better than WAN sourced time, because
    there will be little network jitter. They will drift in relation to
    true time, but ought to keep together well, as long as there isn't too
    large an offset between server and client natural clock frequencies.

    However, for a high percentile of system times being within 1ms of the
    reference, he probably should be using PPS timing with equal length
    cables between the timing source and all the machines. Note that
    no-one can guarantee a 100 percentile <1ms performance.

    One other factor to bear in mind is that time is of no use without some
    real world event to time. Interrupt latencies or polling delays for the
    device drivers that capture those events may also compromise the
    1ms. The reason that both Linux and Windows lose interrupts is that they
    have interrupt latencies longer than the chosen clock tick (especially
    if Linux tick gets set to 1000Hz (1ms).

    > The 20 millisecond network delay between buildings seems excessive and
    > may cause problems. The maximum error in transmitting time from server


    That certainly rings alarm bells. One really needs to know much more
    about the technology involved. Only if the delay were purely the result
    of using an analogue delay line (which is a silly suggestion), in both
    directions, would it not affect timing. What matters is any asymmetry,
    and the uncertainty in the delay from packet to packet.

  4. Re: Best solution for millisecond accuracy

    "edouard funke" wrote in message
    news:aa8dc880703231024t7f95ceb6y2159195db0926515@m ail.gmail.com...
    [...]
    > is the accuracy of a millisecond "achievable" in those conditions ?
    > If not, what can i do to achieve it ?


    A millisecond is hard to achieve anyway. If you want to have that _and_
    do real work with your machines, it virtually requires a single PPS
    signal distributed to all your machines. Peering your servers certainly
    won't help.

    With GPS ruled out, a TCXO or OCXO may be good enough, or you may need
    a Rubidium oscillator. I don't know if the Windows port even supports
    PPS yet. ISTR it didn't in the past.

    Groetjes,
    Maarten Wiltink



  5. Re: Best solution for millisecond accuracy


    >However, for a high percentile of system times being within 1ms of the
    >reference, he probably should be using PPS timing with equal length
    >cables between the timing source and all the machines.


    Don't worry about the cable length until you get down to the microseconds.

    The speed of light is 1 ft per nanosecond. That's in vacuum. It's slower
    in cable. 1/2 or 3/4 is a good guess.

    So 50 ft of cable is 100 ns or 1/10 of a microsecond or
    1/10000 of a millisecond.


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


  6. Re: Best solution for millisecond accuracy

    David Woolley wrote:
    > In article <46043069.1010200@comcast.net>,
    > Richard B. gilbert wrote:
    >> edouard funke wrote:

    >
    >>> - change OS (again what is the impact ?)

    >> Some operating systems keep time a little better than others. Windows
    >> and Linux have both been known to lose clock interrupts during periods
    >> of high disk usage. I've had good results with Solaris (8, 9, & 10) but
    >> others here seem to have had results differing from mine!

    >
    > Also, Windows, in default configuration, will only provide a resolution
    > of about 15 to 20ms (whatever the clock interrupt rate is) in the times
    > provided to application programs. ntpd plays tricks to make its own times
    > more accurate, and therefore the phase of the system clock more accurate,
    > but, in my experience, that breaks down when the system is heavily loaded.
    >
    > It is possible that enabling multimedia timers will improve the resolution
    > of time supplied to application programs; I haven't tested this.


    The Windows implementation uses the multimedia timers to provide the
    greatest accuracy.

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


  7. Re: Best solution for millisecond accuracy

    Hal Murray wrote:
    >> However, for a high percentile of system times being within 1ms of the
    >> reference, he probably should be using PPS timing with equal length
    >> cables between the timing source and all the machines.

    >
    > Don't worry about the cable length until you get down to the microseconds.
    >
    > The speed of light is 1 ft per nanosecond. That's in vacuum. It's slower
    > in cable. 1/2 or 3/4 is a good guess.
    >
    > So 50 ft of cable is 100 ns or 1/10 of a microsecond or
    > 1/10000 of a millisecond.
    >
    >


    The length of the cable is almost never the problem. The real problem is
    asymmetry in the the time needed to send and receive the packets which
    is almost impossible to estimate. If you know the asymmetry every time
    you can get a very good estimate of the delay and therefore you could
    get a very good results for you clock.

    Danny

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


  8. Re: Best solution for millisecond accuracy

    Danny Mayer wrote:
    > edouard funke wrote:
    >> Hi,
    >>
    >> I am running several (less than 30) servers on LAN with these restrictions :
    >> - no Internet
    >> - Windows XP/2003


    Oops! Windows! You lose.

    >> - no GPS possible
    >> - I need less than a millisecond accuracy.
    >>

    >
    > Submillisecond requires a refclock at a minimum. On a network even with


    The real problem is that no Windows machine has much better than 10 ms
    resolution from the system clock, so that even if NTPD can synthesize a
    more accurate clock for internal protocol use, your time-using programs
    won't have access to it.

    Go download a better OS instead.
    :-(

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"

  9. Re: Best solution for millisecond accuracy

    Danny,

    Danny Mayer wrote:
    > David Woolley wrote:
    >> In article <46043069.1010200@comcast.net>,
    >> Richard B. gilbert wrote:
    >>> edouard funke wrote:

    >>
    >>>> - change OS (again what is the impact ?)
    >>> Some operating systems keep time a little better than others. Windows
    >>> and Linux have both been known to lose clock interrupts during periods
    >>> of high disk usage. I've had good results with Solaris (8, 9, & 10) but
    >>> others here seem to have had results differing from mine!

    >>
    >> Also, Windows, in default configuration, will only provide a resolution
    >> of about 15 to 20ms (whatever the clock interrupt rate is) in the times
    >> provided to application programs. ntpd plays tricks to make its own
    >> times more accurate, and therefore the phase of the system clock more
    >> accurate, but, in my experience, that breaks down when the system is
    >> heavily loaded.
    >>
    >> It is possible that enabling multimedia timers will improve the
    >> resolution of time supplied to application programs; I haven't tested
    >> this.

    >
    > The Windows implementation uses the multimedia timers to provide the
    > greatest accuracy.


    Not quite. It uses the PerformanceCounter API to interpolate between timer
    ticks. The PerformanceCounter API traditionally gets its time stamps from
    the timer chip, or from the CPU's time stamp counter (TSC), depending on
    the HAL which is installed on the particular machine.

    AFAIK there are some even more different HALs available on very recent
    Windows versions.

    The multimedia timers are only (optionally) set to highest resolution by the
    Windows port of ntpd because otherwise the Windows system time would seem
    to step back and forth whenever another program on that machine would
    change the MM timer.

    BTW, first tests with Vista showed that the Windows system clock resolution
    has been increased to 1 millisecond under Vista. However, the MM timer
    issues are still present.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread