time delta between clients - NTP

This is a discussion on time delta between clients - NTP ; Kevin Oberman wrote: > > 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 44

Thread: time delta between clients

  1. Re: time delta between clients

    Kevin Oberman wrote:
    >
    > 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.


    This one is really interesting. We should add this reference into our
    support web. I haven't looked at the design of this but there may be a
    case to include it into NTP.

    Danny

  2. 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


    Don't do that. You need at *least* 4 servers listed here. Two is very
    bad since you have very few ways of telling which clock is better. peer
    is useful for comparing how other systems are doing but it will
    sometimes discipline your system clock if nothing better is available.
    You should use iburst on all lines to speed up initial convergence to a
    stable state.

    If this is one of your neverending testing workbenches consider getting
    one of HP's clocks (or is it owned by Agilent now?). Even better, a
    cesium clock!

    Danny

  3. Re: time delta between clients

    Per Hedeland wrote:
    > 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.
    >


    While Rick may be a relative newbie to NTP he has had years of
    conducting performance analysis of applications and systems. His
    performance testing of BIND9 is probably *the* seminal reference on DNS
    testing.

    Danny

  4. Re: time delta between clients

    In article <476B3C9C.8090607@ntp.isc.org> mayer@ntp.isc.org (Danny
    Mayer) writes:
    >Per Hedeland wrote:
    >> 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.
    >>

    >
    >While Rick may be a relative newbie to NTP he has had years of
    >conducting performance analysis of applications and systems. His
    >performance testing of BIND9 is probably *the* seminal reference on DNS
    >testing.


    Uh, your point being? I'm sure your description is correct even though I
    have no knowledge of that subject (which doesn't seem to be relevant
    here), and I specifically said that I *didn't* consider Rick a newbie to
    NTP - based on the very limited knowledge of *that* subject that I have,
    namely past postings in this forum. Which is why I found his statement
    surprising, and assumed that I must be misunderstanding it. Are you
    saying that you agree with that statement? Or maybe you can explain how
    I'm misunderstanding it?

    --Per Hedeland
    per@hedeland.org

  5. Using a PPS source without a GPS receiver?

    The setup: O(10) FreeBSD 6.2 machines in a rack, a PPS source, and an
    NTP server somewhere on the same network. Is it possible (and if so,
    how?) to configure ntpd on these machines so they get the rough time
    over NTP from the network's NTP server, and use the PPS source so they
    stay better synchronized to each other (with less than a foot of coax
    between each machine, I'm not worried about the extra nanosecond!)

    Thanks,

    /ji

  6. Re: Using a PPS source without a GPS receiver?

    > The setup: O(10) FreeBSD 6.2 machines in a rack, a PPS source, and an
    > NTP server somewhere on the same network. Is it possible (and if so,
    > how?) to configure ntpd on these machines so they get the rough time
    > over NTP from the network's NTP server, and use the PPS source so they
    > stay better synchronized to each other (with less than a foot of coax
    > between each machine, I'm not worried about the extra nanosecond!)


    http://www.ece.udel.edu/~mills/ntp/h.../driver22.html

    Setup PPS using the PPS Clock Discipline (driver 22), then set another line
    using a NTP server and use the PREFER keyword... It's all there on the page.

  7. Re: time delta between clients

    Per Hedeland wrote:
    > In article <476B3C9C.8090607@ntp.isc.org> mayer@ntp.isc.org (Danny
    > Mayer) writes:
    >> Per Hedeland wrote:
    >>> 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.
    >>>

    >> While Rick may be a relative newbie to NTP he has had years of
    >> conducting performance analysis of applications and systems. His
    >> performance testing of BIND9 is probably *the* seminal reference on DNS
    >> testing.

    >
    > Uh, your point being? I'm sure your description is correct even though I
    > have no knowledge of that subject (which doesn't seem to be relevant
    > here), and I specifically said that I *didn't* consider Rick a newbie to
    > NTP - based on the very limited knowledge of *that* subject that I have,
    > namely past postings in this forum. Which is why I found his statement
    > surprising, and assumed that I must be misunderstanding it. Are you
    > saying that you agree with that statement? Or maybe you can explain how
    > I'm misunderstanding it?
    >
    > --Per Hedeland
    > per@hedeland.org


    Well, lets see if we can reduce the confusion a little. ;-)

    Rick (Jones) is the author of netperf. He deals with quite a large number
    of platforms, releases of those platforms, and combinations thereof.
    Tom (Smith) happens to work for the same company as Rick, also deals
    with quite a large number of platforms, releases, combinations, and with
    customers with large heterogeneous and problematic NTP networks, among
    other things.

    Per's question was to Tom's comment, not Rick's, and Tom's comment was to Rick,
    not Per. I imagine Rick may be just sitting on the sidelines scratching his head at
    this point wondering what he did wrong.

    -Tom

  8. Re: time delta between clients

    In article <476DCB00.3090008@alum.mit.edu> Tom Smith
    writes:
    >Per Hedeland wrote:
    >> In article <476B3C9C.8090607@ntp.isc.org> mayer@ntp.isc.org (Danny
    >> Mayer) writes:
    >>> Per Hedeland wrote:
    >>>> 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.
    >>>>
    >>> While Rick may be a relative newbie to NTP he has had years of
    >>> conducting performance analysis of applications and systems. His
    >>> performance testing of BIND9 is probably *the* seminal reference on DNS
    >>> testing.

    >>
    >> Uh, your point being? I'm sure your description is correct even though I
    >> have no knowledge of that subject (which doesn't seem to be relevant
    >> here), and I specifically said that I *didn't* consider Rick a newbie to
    >> NTP - based on the very limited knowledge of *that* subject that I have,
    >> namely past postings in this forum. Which is why I found his statement
    >> surprising, and assumed that I must be misunderstanding it. Are you
    >> saying that you agree with that statement? Or maybe you can explain how
    >> I'm misunderstanding it?

    >
    >Well, lets see if we can reduce the confusion a little. ;-)
    >
    >Rick (Jones) is the author of netperf. He deals with quite a large number
    >of platforms, releases of those platforms, and combinations thereof.
    >Tom (Smith) happens to work for the same company as Rick, also deals
    >with quite a large number of platforms, releases, combinations, and with
    >customers with large heterogeneous and problematic NTP networks, among
    >other things.
    >
    >Per's question was to Tom's comment, not Rick's, and Tom's comment was to Rick,
    >not Per. I imagine Rick may be just sitting on the sidelines scratching
    >his head at this point wondering what he did wrong.


    Thanks for that - I actually knew that I was responding to Tom
    initially:-), and will blame Danny's message (which then seems even more
    pointless) for making me mix up the names...:-) Now I'm just wondering
    if Tom Smith at alum.mit.edu is the same person as Tom Smith at
    cag.zko.hp.com?:-) Well, I guess I'm also still wondering whether the
    latter is actually saying that it won't be possible to get the skew
    below 20 ms with Unix hosts with 100Hz clocks, but it's not really
    important - the important thing is that such a statement (if made) is
    not correct.

    --Per Hedeland
    per@hedeland.org


  9. Re: time delta between clients

    Per Hedeland wrote:
    > Well, I guess I'm also still wondering whether the
    > latter is actually saying that it won't be possible to get the skew
    > below 20 ms with Unix hosts with 100Hz clocks, but it's not really
    > important - the important thing is that such a statement (if made) is
    > not correct.
    >


    Well, first I missed it if Rick said he was exclusively concerned about
    UNIX hosts. Second, if you check, my comment was also not exclusively about
    UNIX hosts, nor about the nominal clock frequency, but about the clock
    resolution, or minimum increment from, for example, gettimeofday(). With
    those thoughts in mind, yes, the comment stands that the skew that can be
    held between any 2 hosts depends on the clock resolutions of the 2 hosts
    and this ranges up to 15-16 milliseconds for some and up to 1 millisecond
    even for some UNIX systems. Since Rick is concerned about differentiating
    delays in the 10s of microseconds over a relatively short test time, this
    might be of some importance to him.

    -Tom

  10. Re: time delta between clients

    In article <476E6824.2010609@cag.zko.hp.com> Tom Smith
    writes:
    >Per Hedeland wrote:
    >> Well, I guess I'm also still wondering whether the
    >> latter is actually saying that it won't be possible to get the skew
    >> below 20 ms with Unix hosts with 100Hz clocks, but it's not really
    >> important - the important thing is that such a statement (if made) is
    >> not correct.
    >>

    >
    >Well, first I missed it if Rick said he was exclusively concerned about
    >UNIX hosts.


    I don't think he did, but in any case both "Unix" and "100Hz" was part
    of the "typical" example I "invented", to see what your statement (as I
    understood it) would imply.

    > Second, if you check, my comment was also not exclusively about
    >UNIX hosts, nor about the nominal clock frequency, but about the clock
    >resolution, or minimum increment from, for example, gettimeofday().


    I can't agree with that, because when I check, what you said was:

    >>>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.


    I certainly understood (and understand) "clock tick interval" to refer
    to the nominal clock frequency - i.e. the thing that is 10 milliseconds
    on a host with a "typical" 100Hz clock. If you actually meant resolution
    / miminum increment from gettimeofday() and the like, I think we're in
    full agreement and your statement does make sense. And as I noted later,
    on current (and not-so-current) Unix systems, that resolution is on the
    order of 1 microsecond. On Windows things are different of course, but
    apparently it's possible to utilize some sort of special-purpose timers
    to get resolution better than clock tick interval there.

    > With
    >those thoughts in mind, yes, the comment stands that the skew that can be
    >held between any 2 hosts depends on the clock resolutions of the 2 hosts
    >and this ranges up to 15-16 milliseconds for some and up to 1 millisecond
    >even for some UNIX systems.


    That may well be true, but I haven't come across a Unix system with
    clock resolution in the millisecond area in many years. But 4.xBSD on
    Vax-11/750 in the eighties did indeed have gettimeofday() resolution ==
    clock tick interval...

    --Per Hedeland
    per@hedeland.org

  11. Re: time delta between clients

    Danny Mayer wrote:
    > While Rick may be a relative newbie to NTP he has had years of
    > conducting performance analysis of applications and systems. His
    > performance testing of BIND9 is probably *the* seminal reference on
    > DNS testing.


    Now _that_ is scary to read

    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...

  12. Re: time delta between clients

    Tom Smith wrote:
    > Well, first I missed it if Rick said he was exclusively concerned
    > about UNIX hosts.


    I don't think I said one way or the other. While "netperf" means
    never turning-ones-nose-up at any OS, I think it would be safe to say
    that various flavors of *nix would be the 99% solutuion here.

    rick jones
    --
    Process shall set you free from the need for rational thought.
    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...

  13. Re: time delta between clients

    Danny Mayer wrote:
    > Don't do that. You need at *least* 4 servers listed here. Two is very
    > bad since you have very few ways of telling which clock is better. peer
    > is useful for comparing how other systems are doing but it will
    > sometimes discipline your system clock if nothing better is available.
    > You should use iburst on all lines to speed up initial convergence to a
    > stable state.


    OK, I will see about doing that on the 2nd.

    > If this is one of your neverending testing workbenches consider
    > getting one of HP's clocks (or is it owned by Agilent now?). Even
    > better, a cesium clock!


    The clocks went to Agilent, whom I believe sold that part of the
    business to another entity.

    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...

  14. Re: time delta between clients

    oberman@es.net (Kevin Oberman) writes:

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


    I think you missed the point: AFAIK, Rick is the author of netperf ;-)

    [...]

    Ulrich

  15. Re: time delta between clients

    Ulrich Windl wrote:
    > oberman@es.net (Kevin Oberman) writes:
    > [...]
    > > Netperf is not really the best way to go. The appropriate tool for
    > > one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/


    > I think you missed the point: AFAIK, Rick is the author of netperf ;-)


    Shhhh! It's a secret!-)

    rick jones

    about to hit-up "management" for aproval to buy a GPS-18 for some
    experiments, unless someone knows of a better device...

    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    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

    Rick,

    Apparently, OWAMP uses NTP timestamps, but the article assumes there is
    a difference between "NTP time" and "system time". Statistically, NTP
    time is an unbiased estimator of UTC and system time is a lowpass
    version of it. The offsets you might consider NTP time represent
    statistical uncertanty of that estimate and should not be used as system
    time.

    Now for one-way delay calculations, which I can't find in the article.
    In cases of severe one-way congestion, which might be the objective, see
    the NTP huff-n'-puff filter, which is designed to prize this out. As for
    swish and sway due to congestion, Chapter 6 of das Buch has a really
    interesting example of a path from here to East Asia with awesome
    one-way congestion. Huff-n'-puff sliced through it like butter. It could
    be that the statistical methods used by huff-n'-puff be useful if
    exported to other applications.

    Theoretically, you can't measure one-way propagation times unless you
    have some other measure such as bit rate. The first experiments to
    measure this was done 30 years ago using the ARPAnet and had some
    success. The code measures the data rate by launching packets of varying
    size and measuring the differential delays.

    I recently tried the same thing in my earlier experiments using the NTP
    daemon ntpd, but wasn't thrilled with the results. For the experiment to
    work right the network should satisfy what is called the Kleinrock
    Assumption, and my dinkly ISDN line to campus fails that assumption.
    Nevertheless, the code is in the ntp-dev version, but currently disabled.

    Dave

    Rick Jones wrote:
    > Ulrich Windl wrote:
    >
    >>oberman@es.net (Kevin Oberman) writes:
    >>[...]
    >>
    >>>Netperf is not really the best way to go. The appropriate tool for
    >>>one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/

    >
    >
    >>I think you missed the point: AFAIK, Rick is the author of netperf ;-)

    >
    >
    > Shhhh! It's a secret!-)
    >
    > rick jones
    >
    > about to hit-up "management" for aproval to buy a GPS-18 for some
    > experiments, unless someone knows of a better device...
    >


  17. 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.


    Before I did that I borrowed a hand-held GPS receiver (Magellan
    "Crossover" IIRC) from someone. Admittedly it will not be a match for
    the GPS18, and may have a "weaker" receiver. But given that _all_
    signal went poof when I entered the building, I suspect the GPS18,
    unless it is much more sensitive, would have lost all signal too

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    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

    On 2008-02-19, Rick Jones wrote:

    > Before I did that I borrowed a hand-held GPS receiver (Magellan
    > "Crossover" IIRC) from someone. Admittedly it will not be a match for
    > the GPS18, and may have a "weaker" receiver. But given that _all_
    > signal went poof when I entered the building, I suspect the GPS18,
    > unless it is much more sensitive, would have lost all signal too


    My GPS18LVC works through a standard US residential roof. But you
    probably have lots of metal in the way. So ... YMWV

    You can extend the serial cable between the GPS and the host system so
    that you can place the receiver where it has a sky view. It may also
    help to place the host system in a location close to the roof. If you
    use a small system which can run off of POE that will simplify the
    cabling a bit.

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

  19. Re: time delta between clients

    Steve Kostecke writes:

    >On 2008-02-19, Rick Jones wrote:


    >> Before I did that I borrowed a hand-held GPS receiver (Magellan
    >> "Crossover" IIRC) from someone. Admittedly it will not be a match for
    >> the GPS18, and may have a "weaker" receiver. But given that _all_
    >> signal went poof when I entered the building, I suspect the GPS18,
    >> unless it is much more sensitive, would have lost all signal too


    >My GPS18LVC works through a standard US residential roof. But you
    >probably have lots of metal in the way. So ... YMWV


    >You can extend the serial cable between the GPS and the host system so
    >that you can place the receiver where it has a sky view. It may also
    >help to place the host system in a location close to the roof. If you
    >use a small system which can run off of POE that will simplify the
    >cabling a bit.


    I run a GPS 18 LVC along 10m of cat5 cable in addition to the 5m cable it
    comes with. Not ideal, but it works. While reflections might be a problem,
    15m is 50ns and the pps is only good to 1usec anyway, and the "time
    reading" is only good for about 3usec as well. So the broadening of the
    pulse by a few 10s of nsec is completely lost in the noise.

    (Ie, I use the usb as a power supply for the receiver-- the red and black
    wires go to the red and two black wires on the GPS, the pink goes to the
    Ack on the parallel port with also a ground connection, and the green and yellow go to the
    transmit/receive on the serial port. )

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


  20. Re: time delta between clients

    Steve Kostecke wrote:
    > My GPS18LVC works through a standard US residential roof. But you
    > probably have lots of metal in the way. So ... YMWV


    Yep - basic concrete, steel and glass US office building - in this
    case a "standard" HP "BigFoot" building.

    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...

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