time delta between clients - NTP

This is a discussion on time delta between clients - NTP ; Some folks have been asking me if it is possible to use netperf to get the one-way latency between two systems, while sending a unidirectional stream of data from one to the other. Netperf already has a TCP_RR test (ping-pong) ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 44

Thread: time delta between clients

  1. time delta between clients

    Some folks have been asking me if it is possible to use netperf to get
    the one-way latency between two systems, while sending a
    unidirectional stream of data from one to the other. Netperf already
    has a TCP_RR test (ping-pong) that will report the average round-trip
    latency (and optionally a histogram of the individual RTTs). That
    though is not a unidirectional test.

    So, I am assuming I need synchronized "clocks." Running ntp on each
    of the two systems on which I would run netperf is not a problem.

    What I'm curious about, and a topic where I would welcome some gentle
    taps with clue bats, is if I can take the difference in offset between
    each client and the time server and ass-u-me that is the difference in
    time between the two clients. Or do I have to do something ntp-like
    in netperf itself between the two systems?

    My tests will typically only run for oh, O(60) seconds at a time, so
    I'm ass-u-me-ing I can ignore issues of the two client clocks rates
    changing much.

    For example, here is ntpq peers output from a pair of machines where I
    might want to do this:

    Client 1:
    ntpq> peers
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    +oslowest.raj 15.4.81.61 2 u 118 128 377 0.123 -1.602 2.723
    +lart.lart 15.235.160.30 5 u 4 128 377 35.639 4.115 1.508
    *shovlhead.nashu .TRUE. 1 u 54 128 377 101.115 -5.273 8.190


    Client 2:

    ntpq> peers
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    +linger.raj 15.4.81.61 2 u 104 128 377 0.151 0.002 0.976
    +lart.lart 15.235.160.30 5 u 97 128 377 35.682 3.556 1.003
    *shovlhead.nashu .TRUE. 1 u 33 128 377 105.602 -0.839 3.267

    I would take the difference in offset - -5.273 - -0.839 - and take
    that to be the difference in time between Client 1 and 2.

    Thoughts, suggestions, pointers etc most welcome,

    rick jones

    BTW, in this case, I disabled the interrupt coalescing on Client 1's
    NIC, which I believe is the reason for the difference in delay between
    Client 1 and 2 and linger.raj - all three are on the same LAN. It
    gets lost in the noise talking to the other two time sources.

    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  2. Re: time delta between clients

    > From: Rick Jones
    > Date: Wed, 12 Dec 2007 00:21:28 +0000 (UTC)
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > Some folks have been asking me if it is possible to use netperf to get
    > the one-way latency between two systems, while sending a
    > unidirectional stream of data from one to the other. Netperf already
    > has a TCP_RR test (ping-pong) that will report the average round-trip
    > latency (and optionally a histogram of the individual RTTs). That
    > though is not a unidirectional test.
    >
    > So, I am assuming I need synchronized "clocks." Running ntp on each
    > of the two systems on which I would run netperf is not a problem.
    >
    > What I'm curious about, and a topic where I would welcome some gentle
    > taps with clue bats, is if I can take the difference in offset between
    > each client and the time server and ass-u-me that is the difference in
    > time between the two clients. Or do I have to do something ntp-like
    > in netperf itself between the two systems?
    >
    > My tests will typically only run for oh, O(60) seconds at a time, so
    > I'm ass-u-me-ing I can ignore issues of the two client clocks rates
    > changing much.
    >
    > For example, here is ntpq peers output from a pair of machines where I
    > might want to do this:
    >
    > Client 1:
    > ntpq> peers
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > +oslowest.raj 15.4.81.61 2 u 118 128 377 0.123 -1.602 2.723
    > +lart.lart 15.235.160.30 5 u 4 128 377 35.639 4.115 1.508
    > *shovlhead.nashu .TRUE. 1 u 54 128 377 101.115 -5.273 8.190
    >
    >
    > Client 2:
    >
    > ntpq> peers
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > +linger.raj 15.4.81.61 2 u 104 128 377 0.151 0.002 0.976
    > +lart.lart 15.235.160.30 5 u 97 128 377 35.682 3.556 1.003
    > *shovlhead.nashu .TRUE. 1 u 33 128 377 105.602 -0.839 3.267
    >
    > I would take the difference in offset - -5.273 - -0.839 - and take
    > that to be the difference in time between Client 1 and 2.
    >
    > Thoughts, suggestions, pointers etc most welcome,
    >
    > rick jones
    >
    > BTW, in this case, I disabled the interrupt coalescing on Client 1's
    > NIC, which I believe is the reason for the difference in delay between
    > Client 1 and 2 and linger.raj - all three are on the same LAN. It
    > gets lost in the noise talking to the other two time sources.
    >
    > --
    > oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    > these opinions are mine, all mine; HP might not want them anyway...
    > feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


    Netperf is not really the best way to go. The appropriate tool for
    one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/

    It requires well synchronized time which is where I became seriously
    involved in this area. We try to keep our OWAMP server clocks in sync to
    <5 microseconds. (And we almost always do.) They are scattered all over
    out backbone from coast to coast.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

  3. Re: time delta between clients

    In article ,
    Rick Jones wrote:

    > taps with clue bats, is if I can take the difference in offset between
    > each client and the time server and ass-u-me that is the difference in
    > time between the two clients. Or do I have to do something ntp-like


    No. If NTP is working properly, it is actually an indication of the
    order of magnitude of the error you can expect in measuring the combination
    of network and system timing. The actual system timing variation should be
    considerably less than this, but there may be a systematic bias, even if
    offset is consistently almost zero.

    The NTP clock discipline will strive to zero the offset, but cannot correct
    for round trip asymmetry. Any individual offset measurement will contain
    a measurement error. That measurement error will be of the same magnitude
    as the measurement error you will get with your application. If you are
    interested in one way latency, you are interested in asymmetry!

    To the extent that the above is not true, either you are making use of
    information not available to NTP (like recent temperature excursions), or
    the NTP algorithms need fixing.

    You need to use local, probably GPS, reference clocks, with pulse per
    second feeds, to remove network asymmetry.

  4. Re: time delta between clients

    David Woolley wrote:
    > In article ,
    > Rick Jones wrote:


    > > taps with clue bats, is if I can take the difference in offset
    > > between each client and the time server and ass-u-me that is the
    > > difference in time between the two clients. Or do I have to do
    > > something ntp-like


    > No. If NTP is working properly, it is actually an indication of the
    > order of magnitude of the error you can expect in measuring the
    > combination of network and system timing. The actual system timing
    > variation should be considerably less than this, but there may be a
    > systematic bias, even if offset is consistently almost zero.


    Systematic bias?

    > The NTP clock discipline will strive to zero the offset, but cannot
    > correct for round trip asymmetry. Any individual offset measurement
    > will contain a measurement error. That measurement error will be of
    > the same magnitude as the measurement error you will get with your
    > application. If you are interested in one way latency, you are
    > interested in asymmetry!


    I think that in 99 cases out of 10 this would be run on a LAN where I
    have a decent expectation of symmetry Or at least the first places
    _I_ would be running it would be on a LAN Netperf can and does get
    run over WAN's where any hope of symmetry is out the window, but I'm
    willing to caveat that in the documentation.

    > To the extent that the above is not true, either you are making use
    > of information not available to NTP (like recent temperature
    > excursions), or the NTP algorithms need fixing.


    > You need to use local, probably GPS, reference clocks, with pulse
    > per second feeds, to remove network asymmetry.


    Is that need, Need, or NEED? Is there is a way to be "good enough"
    without having the dependence upon anything more than the two
    endpoints being sync'ed to the same time source? (Other than the same
    GPS constellation received independently by each via their own PPS
    pucks that is)

    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  5. Re: time delta between clients

    Rick Jones wrote:
    >
    >
    >> The NTP clock discipline will strive to zero the offset, but cannot
    >> correct for round trip asymmetry. Any individual offset measurement
    >> will contain a measurement error. That measurement error will be of
    >> the same magnitude as the measurement error you will get with your
    >> application. If you are interested in one way latency, you are
    >> interested in asymmetry!
    >>

    >
    > I think that in 99 cases out of 10 this would be run on a LAN where I
    > have a decent expectation of symmetry Or at least the first places
    > _I_ would be running it would be on a LAN Netperf can and does get
    > run over WAN's where any hope of symmetry is out the window, but I'm
    > willing to caveat that in the documentation.
    >
    > ...
    >
    > Is that need, Need, or NEED? Is there is a way to be "good enough"
    > without having the dependence upon anything more than the two
    > endpoints being sync'ed to the same time source? (Other than the same
    > GPS constellation received independently by each via their own PPS
    > pucks that is)
    >
    >

    well, I guess the point is, if you think it's going to be symmetric
    anyway (in your almost guaranteed sense), why not just simplify
    tremendously, run ping, and divide by 2?

    Otherwise, you'll have to use something like OWAMP and follow it's
    prerequisites.

  6. Re: time delta between clients

    Rick Jones wrote:
    > David Woolley wrote:
    >
    >>In article ,
    >>Rick Jones wrote:

    >
    >
    >>>taps with clue bats, is if I can take the difference in offset
    >>>between each client and the time server and ass-u-me that is the
    >>>difference in time between the two clients. Or do I have to do
    >>>something ntp-like

    >>

    >
    >>No. If NTP is working properly, it is actually an indication of the
    >>order of magnitude of the error you can expect in measuring the
    >>combination of network and system timing. The actual system timing
    >>variation should be considerably less than this, but there may be a
    >>systematic bias, even if offset is consistently almost zero.

    >
    >
    > Systematic bias?
    >
    >>The NTP clock discipline will strive to zero the offset, but cannot
    >>correct for round trip asymmetry. Any individual offset measurement
    >>will contain a measurement error. That measurement error will be of
    >>the same magnitude as the measurement error you will get with your
    >>application. If you are interested in one way latency, you are
    >>interested in asymmetry!

    >
    >
    > I think that in 99 cases out of 10 this would be run on a LAN where I
    > have a decent expectation of symmetry Or at least the first places
    > _I_ would be running it would be on a LAN Netperf can and does get
    > run over WAN's where any hope of symmetry is out the window, but I'm
    > willing to caveat that in the documentation.
    >
    >
    >>To the extent that the above is not true, either you are making use
    >>of information not available to NTP (like recent temperature
    >>excursions), or the NTP algorithms need fixing.

    >
    >
    >>You need to use local, probably GPS, reference clocks, with pulse
    >>per second feeds, to remove network asymmetry.

    >
    >
    > Is that need, Need, or NEED? Is there is a way to be "good enough"
    > without having the dependence upon anything more than the two
    > endpoints being sync'ed to the same time source? (Other than the same
    > GPS constellation received independently by each via their own PPS
    > pucks that is)
    >


    Define "good enough"! How close must synchronization be between
    machines on your LAN? How accurate must the time be?

    Note that having a stable source of time, such as a GPS receiver, can
    strongly affect the tightness of synchronization. It's analogous to the
    difference in difficulty of hitting a stationary target versus a moving
    target.

    I've done it with and without GPS. GPS is better as long as you can
    site an antenna with a good view of the sky. With GPS I can keep the
    herd within one millisecond.



  7. Re: time delta between clients

    Richard B. Gilbert wrote:
    > Rick Jones wrote:
    > > David Woolley wrote:
    > >
    > >>In article ,
    > >>Rick Jones wrote:

    > >
    > >
    > >>>taps with clue bats, is if I can take the difference in offset
    > >>>between each client and the time server and ass-u-me that is the
    > >>>difference in time between the two clients. Or do I have to do
    > >>>something ntp-like
    > >>

    > >
    > >>No. If NTP is working properly, it is actually an indication of the
    > >>order of magnitude of the error you can expect in measuring the
    > >>combination of network and system timing. The actual system timing
    > >>variation should be considerably less than this, but there may be a
    > >>systematic bias, even if offset is consistently almost zero.

    > >
    > >
    > > Systematic bias?
    > >
    > >>The NTP clock discipline will strive to zero the offset, but cannot
    > >>correct for round trip asymmetry. Any individual offset measurement
    > >>will contain a measurement error. That measurement error will be of
    > >>the same magnitude as the measurement error you will get with your
    > >>application. If you are interested in one way latency, you are
    > >>interested in asymmetry!

    > >
    > >
    > > I think that in 99 cases out of 10 this would be run on a LAN where I
    > > have a decent expectation of symmetry Or at least the first places
    > > _I_ would be running it would be on a LAN Netperf can and does get
    > > run over WAN's where any hope of symmetry is out the window, but I'm
    > > willing to caveat that in the documentation.
    > >
    > >
    > >>To the extent that the above is not true, either you are making use
    > >>of information not available to NTP (like recent temperature
    > >>excursions), or the NTP algorithms need fixing.

    > >
    > >
    > >>You need to use local, probably GPS, reference clocks, with pulse
    > >>per second feeds, to remove network asymmetry.

    > >
    > >
    > > Is that need, Need, or NEED? Is there is a way to be "good enough"
    > > without having the dependence upon anything more than the two
    > > endpoints being sync'ed to the same time source? (Other than the same
    > > GPS constellation received independently by each via their own PPS
    > > pucks that is)
    > >


    > Define "good enough"! How close must synchronization be between
    > machines on your LAN? How accurate must the time be?


    Well, if the RTT measured by netperf TCP_RR is any indication:

    [root@bl480c1 netperf2_trunk]# netperf -t TCP_RR -v2 -H bl480c2 -c -C
    TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bl480c2.raj (10.208.0.27) port 0 AF_INET : first burst 0
    Local /Remote
    Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem
    Send Recv Size Size Time Rate local remote local remote
    bytes bytes bytes bytes secs. per sec % S % S us/Tr us/Tr

    87380 87380 1 1 10.00 19834.15 2.20 2.29 8.888 9.222
    87380 87380
    Alignment Offset RoundTrip Trans Throughput
    Local Remote Local Remote Latency Rate 10^6bits/s
    Send Recv Send Recv usec/Tran per sec Outbound Inbound
    8 0 0 0 50.418 19834.148 0.159 0.159

    I'm presently seeing round-trip times user space to user space, and
    with interrupt coalescing disabled (not the default) of 50
    microseconds. Some folks have reported better TCP_RR perf with other
    interconnects (the above was simply Gigabit Ethernet). So, we are
    talking small numbers of microseconds.

    > Note that having a stable source of time, such as a GPS receiver,
    > can strongly affect the tightness of synchronization. It's
    > analogous to the difference in difficulty of hitting a stationary
    > target versus a moving target.


    > I've done it with and without GPS. GPS is better as long as you can
    > site an antenna with a good view of the sky. With GPS I can keep
    > the herd within one millisecond.


    Most of what I do is down in the bowels of corporate machine rooms,
    far from windows, which doesn't fill me with confidence about getting
    a good view of the sky

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  8. Re: time delta between clients

    In article Rick Jones
    writes:
    >
    >For example, here is ntpq peers output from a pair of machines where I
    >might want to do this:
    >
    >Client 1:
    >ntpq> peers
    > remote refid st t when poll reach delay offset jitter
    >================================================== ============================
    >+oslowest.raj 15.4.81.61 2 u 118 128 377 0.123 -1.602 2.723
    >+lart.lart 15.235.160.30 5 u 4 128 377 35.639 4.115 1.508
    >*shovlhead.nashu .TRUE. 1 u 54 128 377 101.115 -5.273 8.190
    >
    >
    >Client 2:
    >
    >ntpq> peers
    > remote refid st t when poll reach delay offset jitter
    >================================================== ============================
    >+linger.raj 15.4.81.61 2 u 104 128 377 0.151 0.002 0.976
    >+lart.lart 15.235.160.30 5 u 97 128 377 35.682 3.556 1.003
    >*shovlhead.nashu .TRUE. 1 u 33 128 377 105.602 -0.839 3.267
    >
    >I would take the difference in offset - -5.273 - -0.839 - and take
    >that to be the difference in time between Client 1 and 2.
    >
    >Thoughts, suggestions, pointers etc most welcome,


    Well, if you want a reasonably accurate estimate on the time difference
    between two hosts on a LAN, it's probably a better idea to ask ntpd to
    provide that directly rather than comparing their offsets to a server
    that is 50 ms removed (presumably across a WAN) and that may not have
    been polled for the last 17 minutes.

    I.e. you could set up the hosts to peer with each other, possibly with a
    lowered maxpoll and/or 'noselect', which would have each give their
    estimated offset to the other directly in the ntpq output. I have no
    idea *how* accurate that would be in absolute terms, but it just has to
    be "better".

    --Per Hedeland
    per@hedeland.org


  9. Re: time delta between clients

    Per Hedeland wrote:

    > Well, if you want a reasonably accurate estimate on the time
    > difference between two hosts on a LAN, it's probably a better idea
    > to ask ntpd to provide that directly rather than comparing their
    > offsets to a server that is 50 ms removed (presumably across a WAN)
    > and that may not have been polled for the last 17 minutes.


    Yeah, that one gets picked I suspect thanks to its stratum. I've
    contemplated removing it from the equation.

    > I.e. you could set up the hosts to peer with each other, possibly
    > with a lowered maxpoll and/or 'noselect', which would have each give
    > their estimated offset to the other directly in the ntpq output. I
    > have no idea *how* accurate that would be in absolute terms, but it
    > just has to be "better".


    I will see about giving that a try.

    I suppose I could also try to see if I can get the powers that be to
    spring for a GPS18 and see if I can indeed get signal in the machine
    room(s) of interest.

    Speaking of which, I was just at the garmin website, and seems they
    now have a GPS18 5HZ in addition to the regular GPS18. Is there any
    benefit to the extra four pulses per second?

    rick jones
    --
    oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  10. Re: time delta between clients

    Rick Jones wrote:
    > Richard B. Gilbert wrote:
    >
    >>Rick Jones wrote:
    >>
    >>>David Woolley wrote:
    >>>
    >>>
    >>>>In article ,
    >>>>Rick Jones wrote:
    >>>
    >>>
    >>>>>taps with clue bats, is if I can take the difference in offset
    >>>>>between each client and the time server and ass-u-me that is the
    >>>>>difference in time between the two clients. Or do I have to do
    >>>>>something ntp-like
    >>>>
    >>>>No. If NTP is working properly, it is actually an indication of the
    >>>>order of magnitude of the error you can expect in measuring the
    >>>>combination of network and system timing. The actual system timing
    >>>>variation should be considerably less than this, but there may be a
    >>>>systematic bias, even if offset is consistently almost zero.
    >>>
    >>>
    >>> Systematic bias?
    >>>
    >>>>The NTP clock discipline will strive to zero the offset, but cannot
    >>>>correct for round trip asymmetry. Any individual offset measurement
    >>>>will contain a measurement error. That measurement error will be of
    >>>>the same magnitude as the measurement error you will get with your
    >>>>application. If you are interested in one way latency, you are
    >>>>interested in asymmetry!
    >>>
    >>>
    >>>I think that in 99 cases out of 10 this would be run on a LAN where I
    >>>have a decent expectation of symmetry Or at least the first places
    >>>_I_ would be running it would be on a LAN Netperf can and does get
    >>>run over WAN's where any hope of symmetry is out the window, but I'm
    >>>willing to caveat that in the documentation.
    >>>
    >>>
    >>>
    >>>>To the extent that the above is not true, either you are making use
    >>>>of information not available to NTP (like recent temperature
    >>>>excursions), or the NTP algorithms need fixing.
    >>>
    >>>
    >>>>You need to use local, probably GPS, reference clocks, with pulse
    >>>>per second feeds, to remove network asymmetry.
    >>>
    >>>
    >>>Is that need, Need, or NEED? Is there is a way to be "good enough"
    >>>without having the dependence upon anything more than the two
    >>>endpoints being sync'ed to the same time source? (Other than the same
    >>>GPS constellation received independently by each via their own PPS
    >>>pucks that is)
    >>>

    >>

    >
    >>Define "good enough"! How close must synchronization be between
    >>machines on your LAN? How accurate must the time be?

    >
    >
    > Well, if the RTT measured by netperf TCP_RR is any indication:
    >
    > [root@bl480c1 netperf2_trunk]# netperf -t TCP_RR -v2 -H bl480c2 -c -C
    > TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bl480c2.raj (10.208.0.27) port 0 AF_INET : first burst 0
    > Local /Remote
    > Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem
    > Send Recv Size Size Time Rate local remote local remote
    > bytes bytes bytes bytes secs. per sec % S % S us/Tr us/Tr
    >
    > 87380 87380 1 1 10.00 19834.15 2.20 2.29 8.888 9.222
    > 87380 87380
    > Alignment Offset RoundTrip Trans Throughput
    > Local Remote Local Remote Latency Rate 10^6bits/s
    > Send Recv Send Recv usec/Tran per sec Outbound Inbound
    > 8 0 0 0 50.418 19834.148 0.159 0.159
    >
    > I'm presently seeing round-trip times user space to user space, and
    > with interrupt coalescing disabled (not the default) of 50
    > microseconds. Some folks have reported better TCP_RR perf with other
    > interconnects (the above was simply Gigabit Ethernet). So, we are
    > talking small numbers of microseconds.
    >
    >
    >>Note that having a stable source of time, such as a GPS receiver,
    >>can strongly affect the tightness of synchronization. It's
    >>analogous to the difference in difficulty of hitting a stationary
    >>target versus a moving target.

    >
    >
    >>I've done it with and without GPS. GPS is better as long as you can
    >>site an antenna with a good view of the sky. With GPS I can keep
    >>the herd within one millisecond.

    >
    >
    > Most of what I do is down in the bowels of corporate machine rooms,
    > far from windows, which doesn't fill me with confidence about getting
    > a good view of the sky


    Can you put a small PC with a GPS receiver on the top floor as a
    dedicated NTP server?

    There are devices (expensive) that will read the time from the reference
    signal of a CDMA cell phone base station and serve time via NTP.



  11. Re: time delta between clients

    Richard B. Gilbert wrote:
    > Can you put a small PC with a GPS receiver on the top floor as a
    > dedicated NTP server?


    Perhaps, but I doubt I could get a "direct line" on the network from
    the systems to it.

    > There are devices (expensive) that will read the time from the
    > reference signal of a CDMA cell phone base station and serve time
    > via NTP.


    I might be able to convince TPTB to fund a GPS18 or GPS185Hz
    "experiment." In this _specific_ instance the building is two stories
    plus a mezzanine. Perhaps I could get lucky.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  12. Re: time delta between clients

    Rick Jones wrote:
    > Richard B. Gilbert wrote:
    >
    >>Can you put a small PC with a GPS receiver on the top floor as a
    >>dedicated NTP server?

    >
    >
    > Perhaps, but I doubt I could get a "direct line" on the network from
    > the systems to it.
    >
    >
    >>There are devices (expensive) that will read the time from the
    >>reference signal of a CDMA cell phone base station and serve time
    >>via NTP.

    >
    >
    > I might be able to convince TPTB to fund a GPS18 or GPS185Hz
    > "experiment." In this _specific_ instance the building is two stories
    > plus a mezzanine. Perhaps I could get lucky.
    >


    You might get something to work without an outside antenna. A great
    deal would depend on just how the building was constructed. Some
    buildings would work as a pretty good "Faraday shield". I can receive
    GPS signals inside my house because it's mostly wood and more or less
    transparent to the frequencies involved. YMMV!







  13. Re: time delta between clients

    Rick Jones wrote:
    []
    > I suppose I could also try to see if I can get the powers that be to
    > spring for a GPS18 and see if I can indeed get signal in the machine
    > room(s) of interest.
    >
    > Speaking of which, I was just at the garmin website, and seems they
    > now have a GPS18 5HZ in addition to the regular GPS18. Is there any
    > benefit to the extra four pulses per second?
    >
    > rick jones


    Rick,

    I have found that, compared to recent GPS receivers, the GPS-18 is not
    very sensitive. For example, I needed to mount the unit outside my
    window:

    http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm

    facing south, to get any signal, whereas my GPSmap 60CSx works fine
    /inside/ the same room. Even outside the window, the approximately
    180-degree sky view resulted in some loss of sync, and I now have the
    GPS-18 on the roof which has a 30 degree slope to the west. Not ideal,
    but better than before.

    There is no advantage to the 5Hz unit with the present NTP implementation.

    Cheers,
    David



  14. Re: time delta between clients

    Doug Hughes wrote:
    > well, I guess the point is, if you think it's going to be symmetric
    > anyway (in your almost guaranteed sense), why not just simplify
    > tremendously, run ping, and divide by 2?


    Then it wouldn't be a unidirectional transfer

    Being the clueless ntpadmin I am, I am not sure I did things correctly
    with the suggestion to setup a peer association, and drop the polling
    intervals, I went ahead and tried to do that with my two systems
    anyway. I also took away the "far away" time servers.

    On bl480c1:
    ntpq> peers
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    bl480c2.raj 10.208.0.1 3 u 13 16 377 0.093 -0.002 0.017
    *linger.raj 15.4.81.61 2 u 2 16 377 0.125 0.155 0.145
    LOCAL(0) .LOCL. 10 l 56 64 377 0.000 0.000 0.001

    On bl480c2, when I initially botched the peer line, saying bl481c1 by
    mistake:

    ntpq> peers
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    *linger.raj 15.4.81.61 2 u 11 16 377 0.139 0.550 0.089
    LOCAL(0) .LOCL. 10 l 27 64 377 0.000 0.000 0.001

    I corrected that - it was interesting to see how far things migrated
    in just the 30 seconds or so ntpd wasn't running on bl480c2. Shortly
    after restarting, the offset reported by bl480c1 was 0.100 rather than
    0.002.

    rick jones
    --
    portable adj, code that compiles under more than one compiler
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  15. Re: time delta between clients

    Rick Jones wrote:
    > On bl480c1:
    > ntpq> peers
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > bl480c2.raj 10.208.0.1 3 u 13 16 377 0.093 -0.002 0.017
    > *linger.raj 15.4.81.61 2 u 2 16 377 0.125 0.155 0.145
    > LOCAL(0) .LOCL. 10 l 56 64 377 0.000 0.000 0.001


    > On bl480c2, when I initially botched the peer line, saying bl481c1 by
    > mistake:


    > ntpq> peers
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > *linger.raj 15.4.81.61 2 u 11 16 377 0.139 0.550 0.089
    > LOCAL(0) .LOCL. 10 l 27 64 377 0.000 0.000 0.001


    > I corrected that - it was interesting to see how far things migrated
    > in just the 30 seconds or so ntpd wasn't running on bl480c2. Shortly
    > after restarting, the offset reported by bl480c1 was 0.100 rather than
    > 0.002.


    And ever since then, I've not seen it anywhere near that 0.002 figure.

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  16. Re: time delta between clients

    In article Rick Jones
    writes:
    >Rick Jones wrote:
    >> On bl480c1:
    >> ntpq> peers
    >> remote refid st t when poll reach delay offset jitter
    >> ================================================== ============================
    >> bl480c2.raj 10.208.0.1 3 u 13 16 377 0.093 -0.002 0.017
    >> *linger.raj 15.4.81.61 2 u 2 16 377 0.125 0.155 0.145
    >> LOCAL(0) .LOCL. 10 l 56 64 377 0.000 0.000 0.001

    >
    >> On bl480c2, when I initially botched the peer line, saying bl481c1 by
    >> mistake:

    >
    >> ntpq> peers
    >> remote refid st t when poll reach delay offset jitter
    >> ================================================== ============================
    >> *linger.raj 15.4.81.61 2 u 11 16 377 0.139 0.550 0.089
    >> LOCAL(0) .LOCL. 10 l 27 64 377 0.000 0.000 0.001

    >
    >> I corrected that - it was interesting to see how far things migrated
    >> in just the 30 seconds or so ntpd wasn't running on bl480c2. Shortly
    >> after restarting, the offset reported by bl480c1 was 0.100 rather than
    >> 0.002.

    >
    >And ever since then, I've not seen it anywhere near that 0.002 figure.


    Did you lower the maxpoll on the server that is actually providing time
    to those two? Don't do that, it prevents ntpd from fine-tuning the
    disciplining of the system clock. Lowering it on the peer setup - which
    is not intended to provide time to either of those two hosts, and so
    could usefully have 'noselect' (if it is available in your version and
    works with "peer", I haven't tried that) - is just so you can have a
    "recent" value for the offset. It would be a good idea to lose the LOCAL
    clock though, it's totally useless for your purpose.

    --Per Hedeland
    per@hedeland.org


  17. Re: time delta between clients

    Per Hedeland wrote:

    > Did you lower the maxpoll on the server that is actually providing time
    > to those two? Don't do that, it prevents ntpd from fine-tuning the
    > disciplining of the system clock.




    > Lowering it on the peer setup - which is not intended to provide
    > time to either of those two hosts, and so could usefully have
    > 'noselect' (if it is available in your version and works with
    > "peer", I haven't tried that) - is just so you can have a "recent"
    > value for the offset. It would be a good idea to lose the LOCAL
    > clock though, it's totally useless for your purpose.


    Here is what I have now that I've dropped the minpoll from the server
    and dropped LOCAL:

    peer bl480c2 minpoll 3 maxpoll 4 iburst
    server 10.208.0.1 iburst
    server 10.0.0.1
    server 10.202.1.1

    I just restarted that on both ends (adjusting peer accordingly) and
    will see how that settles-in.

    thanks,

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  18. Re: time delta between clients

    Rick Jones wrote:
    > Here is what I have now that I've dropped the minpoll from the server
    > and dropped LOCAL:


    > peer bl480c2 minpoll 3 maxpoll 4 iburst
    > server 10.208.0.1 iburst
    > server 10.0.0.1
    > server 10.202.1.1


    Scratch that - I commented-out the last two servers.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  19. Re: time delta between clients

    Rick Jones wrote:
    > Rick Jones wrote:
    >> Here is what I have now that I've dropped the minpoll from the server
    >> and dropped LOCAL:

    >
    >> peer bl480c2 minpoll 3 maxpoll 4 iburst
    >> server 10.208.0.1 iburst
    >> server 10.0.0.1
    >> server 10.202.1.1

    >
    > Scratch that - I commented-out the last two servers.
    >
    > rick jones


    I think you may have problems, even in the mythical zero-latency network,
    getting the skew consistently below double the clock tick of the system
    with the largest clock tick interval. With the skew you're looking for,
    you'd need systems with microsecond clock accuracy and resolution, and that
    probably means systems with one or another iterations on the way to the
    "nano-kernel".

    -Tom

  20. Re: time delta between clients

    In article <4761F0AA.3060003@cag.zko.hp.com> Tom Smith
    writes:
    >Rick Jones wrote:
    >> Rick Jones wrote:
    >>> Here is what I have now that I've dropped the minpoll from the server
    >>> and dropped LOCAL:

    >>
    >>> peer bl480c2 minpoll 3 maxpoll 4 iburst
    >>> server 10.208.0.1 iburst
    >>> server 10.0.0.1
    >>> server 10.202.1.1

    >>
    >> Scratch that - I commented-out the last two servers.
    >>
    >> rick jones

    >
    >I think you may have problems, even in the mythical zero-latency network,
    >getting the skew consistently below double the clock tick of the system
    >with the largest clock tick interval.


    Hm, if you were a newbie here, I'd assume that you simply don't know
    what you're talking about, but since you aren't, I must be
    misunderstanding you as you appear to be saying that two Unix hosts with
    the traditional 100 Hz clock (on the same LAN) couldn't achieve a skew
    consistently below 20 ms - while (at least) sub-millisecond offsets in
    such setups are commonplace and discussed here every other day.
    Apparently not even Windows has the kind of problem you suggest anymore.

    > With the skew you're looking for,
    >you'd need systems with microsecond clock accuracy and resolution, and that
    >probably means systems with one or another iterations on the way to the
    >"nano-kernel".


    Again I think I must be misunderstanding you, since virtually all Unix
    systems have had microsecond clock *resolution* for many years.

    --Per Hedeland
    per@hedeland.org

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast