LAN synch question - NTP

This is a discussion on LAN synch question - NTP ; Hello, I am conducting research with TDMA on a wired emulated network. I want all of the machines in the experiment to have the same time. Ideally, the maximum offset would be on the order of 100 micro- seconds. The ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: LAN synch question

  1. LAN synch question

    Hello,
    I am conducting research with TDMA on a wired emulated network. I
    want all of the machines in the experiment to have the same time.
    Ideally, the maximum offset would be on the order of 100 micro-
    seconds. The machines are connected by a 1 Gbps LAN so delay is not a
    problem. Additionally, I don't care about the correctness of the clock
    compared to global time. I am curious what is he best way to set this
    up. I was thinking to have on dedicated ntp server that operated in
    broadcast mode, and also configure the clients to poll it every 16
    seconds. Additionally, there are two planes: experimental and
    control. Since the experimental traffic is separated from the control
    traffic, there should be little variance in delay for ntp packets.

    Thanks,

    Roman

  2. Re: LAN synch question

    I just want to clarify something. ntpdc can be used to check on the
    offset from the peer, right? What is the smallest offset in clocks
    that I can expect on a 1 Gbps LAN?

    Thanks


  3. Re: LAN synch question

    On 2008-09-11, rochertov@gmail.com wrote:

    > I am conducting research with TDMA on a wired emulated network. I want
    > all of the machines in the experiment to have the same time.


    [snip]

    > Additionally, I don't care about the correctness of the clock compared
    > to global time.


    This is a common misunderstanding of NTP.

    NTP synchronizes clocks to a common time-base across a network.

    UTC is ubiquitous and easily acquired via a network or a radio clock
    (e.g. a sub $70 timing GPS). It is the time-base customarily used by
    NTP. You may, of course, substitute your own time-base.

    > I am curious what is he best way to set this up. I was thinking to
    > have on dedicated ntp server that operated in broadcast mode, and
    > also configure the clients to poll it every 16 seconds. Additionally,
    > there are two planes: experimental and control. Since the experimental
    > traffic is separated from the control traffic, there should be little
    > variance in delay for ntp packets.


    You need to discipline the clock in your reference server so that it is
    stable (i.e. each tick has exactly the same duration). Otherwise the
    client systems will be chasing a moving target and you will be hard
    pressed to meet your stated offset requirement of 100us.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  4. Re: LAN synch question

    On 2008-09-11, rochertov@gmail.com wrote:

    > I just want to clarify something. ntpdc can be used to check on the
    > offset from the peer, right?


    ntpq is the recommended diagnostic tool.

    'ntpq -p hostname' returns a billboard which shows that ntpd's view of
    its time sources. If you don't provide a hostname on the command-line
    ntpq uses localhost.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  5. Re: LAN synch question

    rochertov@gmail.com wrote:
    > I just want to clarify something. ntpdc can be used to check on the
    > offset from the peer, right? What is the smallest offset in clocks


    You cannot find out the offset from the peer; to do that you need to
    synhronise an independent clock to an order of magnitude better, then
    read the two software clocks relative to that alternative time
    synchronisation mechanism.

    The value you get for offset is the difference between a smoothed
    estimate of the true time, based on measurements over an extended
    period, and an average of the most recent measured times from the active
    servers. The latter should contain a lot more measurement noise than
    the former.

    > that I can expect on a 1 Gbps LAN?


    Depends on interrupt latency, network loading, the total lack of any
    Windows machines in the time synchronisation chain, etc. 100ns should
    be possible for lightly loaded machines on a lightly loaded network, at
    least 90% of the time.

    However, my feeling is that the only acceptable solution in your case
    would be to feed a pulse per second signal into a PCI or ISA connected
    serial or parallel port (not USB) from the same line driver. You will
    need an OS with kernel PPS support.

    To use 100ns timing in your applications, you will need an OS and
    hardware that support a timing source with maybe 10ns resolution. This
    excludes Windows and any OS more then about 3 or 4 years old.

    Note that broadcast mode will be critically dependent on the initial
    calibration exchange.

  6. Re: LAN synch question

    Thank you for the responses. I just have a few small clarification
    questions.
    I have used ntpdc and ntpq on the same machine that tries to synch
    with an
    ntp server (192.168.0.4). The ntp server uses its own system clock
    which is
    not disciplined (need to figure out how to do that). I am curious as
    to why
    the reported offsets are different.

    ntpdc> peers
    remote local st poll reach delay offset disp
    ================================================== ========
    =LOCAL(0) 127.0.0.1 5 64 377 0.00000 0.000000
    0.03059
    *192.168.0.4 192.168.0.20 6 16 377 0.00011 0.007474
    0.02922

    [root@term1 etc]# ntpq -p ntp
    remote refid st t when poll reach delay
    offset jitter
    ================================================== ========
    192.168.0.255 .BCST. 16 u - 64 0 0.000
    0.000 0.001
    *LOCAL(0) .LOCL. 5 l 51 64 377 0.000
    0.000 0.001


    Also, David, did you mean 100 nano-seconds or 100 micro-seconds? I
    would be
    totally fine with 100 micro-seconds. Would that be achievable if I
    get a GPS
    clock for the ntp server and keep the rest of the setup the same?
    (These are
    Linux 2.6.24 machines). (an info about a cheap Linux compatible clock
    would
    be greatly appreaciated).

    Many Thanks,

  7. Re: LAN synch question

    David Woolley wrote:
    > Depends on interrupt latency, network loading, the total lack of any
    > Windows machines in the time synchronisation chain, etc. 100ns should
    > be possible for lightly loaded machines on a lightly loaded network, at
    > least 90% of the time.


    Sorry. I got 100 microseconds and 100 ns mixed up. However, whilst 100
    microseconds is rather easier to achieve, if you want 100% reliability,
    I still think the common PPS line would be advisable. Caveats about
    Windows still apply.

  8. Re: LAN synch question

    On Sep 11, 3:06 pm, David Woolley
    wrote:
    > David Woolley wrote:
    > > Depends on interrupt latency, network loading, the total lack of any
    > > Windows machines in the time synchronisation chain, etc. 100ns should
    > > be possible for lightly loaded machines on a lightly loaded network, at
    > > least 90% of the time.

    >
    > Sorry. I got 100 microseconds and 100 ns mixed up. However, whilst 100
    > microseconds is rather easier to achieve, if you want 100% reliability,
    > I still think the common PPS line would be advisable. Caveats about
    > Windows still apply.


    We don't have any Windows boxes on the experimental network. Can you
    please recommend a cheap PPS line?

  9. Re: LAN synch question

    rochertov@gmail.com wrote:
    > I have used ntpdc and ntpq on the same machine that tries to synch
    > with an
    > ntp server (192.168.0.4). The ntp server uses its own system clock
    > which is
    > not disciplined (need to figure out how to do that). I am curious as
    > to why
    > the reported offsets are different.


    You have run ntpdc against the client and ntpq against the server,
    probably at slightly different times, as well. ntpdc reports in seconds
    and ntpq in milliseconds.

    >
    > ntpdc> peers
    > remote local st poll reach delay offset disp
    > ================================================== ========
    > =LOCAL(0) 127.0.0.1 5 64 377 0.00000 0.000000
    > 0.03059
    > *192.168.0.4 192.168.0.20 6 16 377 0.00011 0.007474
    > 0.02922


    This is brinkmanship. You only get away with it because there is a
    built in bias against the local clock, even though its stratum favours
    it. You should never use it on pure clients and you should make sure it
    is outvoted by real servers.

    >
    > [root@term1 etc]# ntpq -p ntp
    > remote refid st t when poll reach delay
    > offset jitter
    > ================================================== ========
    > 192.168.0.255 .BCST. 16 u - 64 0 0.000
    > 0.000 0.001
    > *LOCAL(0) .LOCL. 5 l 51 64 377 0.000
    > 0.000 0.001


    Local clock at stratum 5 plus broadcast client is not sensible. A more
    detailed explanation in another thread.
    >
    >
    > Also, David, did you mean 100 nano-seconds or 100 micro-seconds? I
    > would be


    Sorry. I got confused. 100ns is getting near the limits for an ideal
    environment. 100 microseconds is often achieved on a lightly loaded
    LAN, with a local reference clock, but may be violated during
    temperature excursions.

  10. Re: LAN synch question

    rochertov@gmail.com wrote:
    > Hello,
    > I am conducting research with TDMA on a wired emulated network. I
    > want all of the machines in the experiment to have the same time.
    > Ideally, the maximum offset would be on the order of 100 micro-
    > seconds. The machines are connected by a 1 Gbps LAN so delay is not a
    > problem. Additionally, I don't care about the correctness of the clock
    > compared to global time. I am curious what is he best way to set this
    > up. I was thinking to have on dedicated ntp server that operated in
    > broadcast mode, and also configure the clients to poll it every 16
    > seconds. Additionally, there are two planes: experimental and
    > control. Since the experimental traffic is separated from the control
    > traffic, there should be little variance in delay for ntp packets.
    >
    > Thanks,
    >
    > Roman


    I don't think you want to both broadcast AND have the clients poll. One
    or the other but not both! When a client is using broadcast mode, it
    initializes by exchanging packets with the broadcast server to determine
    the typical value of delay. It then uses this figure to correct
    subequent broadcast packets.

+ Reply to Thread