frequency adjusting only - NTP

This is a discussion on frequency adjusting only - NTP ; Hi, I would like to know if NTP (and particularly ntpd) is able to synchronise a clock, only playing with the frequency. I want to avoid any step in the clock that would probably screw up my network appli. thanks, ...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 94

Thread: frequency adjusting only

  1. frequency adjusting only

    Hi,

    I would like to know if NTP (and particularly ntpd) is able to synchronise a
    clock,
    only playing with the frequency.
    I want to avoid any step in the clock that would probably screw up my
    network appli.

    thanks,
    Maxime

    --
    Maxime Louvel
    0044 7964 5555 80
    43 Allen road
    Whitemore reans
    WV60AW Wolverhampton
    United Kingdom

  2. Re: frequency adjusting only

    >>> In article , m.louvel@gmail.com (maxime louvel) writes:

    maxime> Hi, I would like to know if NTP (and particularly ntpd) is able to
    maxime> synchronise a clock, only playing with the frequency. I want to
    maxime> avoid any step in the clock that would probably screw up my network
    maxime> appli.

    It's *possible* and it can be a really bad idea.

    For most folks, only steps *backward* are a problem.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  3. Re: frequency adjusting only

    Harlan Stenn writes:

    >>>> In article , m.louvel@gmail.com (maxime louvel) writes:


    >maxime> Hi, I would like to know if NTP (and particularly ntpd) is able to
    >maxime> synchronise a clock, only playing with the frequency. I want to
    >maxime> avoid any step in the clock that would probably screw up my network
    >maxime> appli.


    >It's *possible* and it can be a really bad idea.


    >For most folks, only steps *backward* are a problem.


    Actually, ntp does synchronize the clock by "playing with the frequency
    only" unless the step size is so large (128ms by default but up to 600sec
    by option) that it will step.

    >--
    >Harlan Stenn
    >http://ntpforum.isc.org - be a member!


  4. Re: frequency adjusting only

    Unruh wrote:
    > Harlan Stenn writes:
    >
    >>>>> In article , m.louvel@gmail.com (maxime louvel) writes:

    >
    >> maxime> Hi, I would like to know if NTP (and particularly ntpd) is able to
    >> maxime> synchronise a clock, only playing with the frequency. I want to
    >> maxime> avoid any step in the clock that would probably screw up my network
    >> maxime> appli.

    >
    >> It's *possible* and it can be a really bad idea.

    >
    >> For most folks, only steps *backward* are a problem.

    >
    > Actually, ntp does synchronize the clock by "playing with the frequency
    > only" unless the step size is so large (128ms by default but up to 600sec
    > by option) that it will step.


    There are two supported settings for this limit, 128ms and 600,000ms,
    but you can set other values, including infinite, with an option that
    comes with severe health warnings. If you set a value of more than
    500ms on systems that implement part of the clock discipline in the
    kernel, you will force them not to use that mechanism, and therefore get
    lower quality time.

    There are also options, unfortunately also with health warnings, that
    can effectively eliminate the main legitimate cause of this, which is
    high asymmetric traffic loads on medium speed internet connections which
    have not been traffic shaped for NTP. If you suffer large steps for
    other reasons, you should fix the underlying cause. Fixing asymmetric
    load can have commercial implications, as only high value ISP accounts
    are likely to support the necessary traffic shaping.

    (Another source of steps is lost clock ticks, but that generally only
    gives the, relatively benign, positive steps.)

    Systems which suffer large steps and aren't allowed to step have been
    reported to hunt (in the control theory sense) rather badly.

    Note, the subject is a little confusing as it could be read as meaning
    that steps are allowed to remain uncorrected. That would be
    unacceptable for a protocol where every node is both client and server.
    That would be like if you had to drive 30 miles and insisted that you
    drove at 30 mph, but you were delayed by a traffic jam, and still
    declared the journey complete after exactly one hour.


  5. Re: frequency adjusting only

    Thanks for your answer,

    I can't have a step on the clock because that would screw up my
    applications.
    However if I keep the load within a certain range I should fine, don't I ?
    I am synchronising one node to several public NTP servers, and the others
    nodes are synchronised to the first one.
    There are 2 to 24 nodes in my sub net.
    Do you think that should be feasible ?

    Maxime

    On Sat, Apr 19, 2008 at 10:34 AM, David Woolley
    wrote:

    > Unruh wrote:
    > > Harlan Stenn writes:
    > >
    > >>>>> In article <

    > dda529d0804160332l3bcb4e43l5623478bc...il.gm ail.com>,
    > m.louvel@gmail.com (maxime louvel) writes:
    > >
    > >> maxime> Hi, I would like to know if NTP (and particularly ntpd) is able

    > to
    > >> maxime> synchronise a clock, only playing with the frequency. I want

    > to
    > >> maxime> avoid any step in the clock that would probably screw up my

    > network
    > >> maxime> appli.

    > >
    > >> It's *possible* and it can be a really bad idea.

    > >
    > >> For most folks, only steps *backward* are a problem.

    > >
    > > Actually, ntp does synchronize the clock by "playing with the frequency
    > > only" unless the step size is so large (128ms by default but up to

    > 600sec
    > > by option) that it will step.

    >
    > There are two supported settings for this limit, 128ms and 600,000ms,
    > but you can set other values, including infinite, with an option that
    > comes with severe health warnings. If you set a value of more than
    > 500ms on systems that implement part of the clock discipline in the
    > kernel, you will force them not to use that mechanism, and therefore get
    > lower quality time.
    >
    > There are also options, unfortunately also with health warnings, that
    > can effectively eliminate the main legitimate cause of this, which is
    > high asymmetric traffic loads on medium speed internet connections which
    > have not been traffic shaped for NTP. If you suffer large steps for
    > other reasons, you should fix the underlying cause. Fixing asymmetric
    > load can have commercial implications, as only high value ISP accounts
    > are likely to support the necessary traffic shaping.
    >
    > (Another source of steps is lost clock ticks, but that generally only
    > gives the, relatively benign, positive steps.)
    >
    > Systems which suffer large steps and aren't allowed to step have been
    > reported to hunt (in the control theory sense) rather badly.
    >
    > Note, the subject is a little confusing as it could be read as meaning
    > that steps are allowed to remain uncorrected. That would be
    > unacceptable for a protocol where every node is both client and server.
    > That would be like if you had to drive 30 miles and insisted that you
    > drove at 30 mph, but you were delayed by a traffic jam, and still
    > declared the journey complete after exactly one hour.
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >




    --
    Maxime Louvel
    0044 7964 5555 80
    43 Allen road
    Whitemore reans
    WV60AW Wolverhampton
    United Kingdom

  6. Re: frequency adjusting only

    >>> In article , m.louvel@gmail.com (maxime louvel) writes:

    maxime> Thanks for your answer, I can't have a step on the clock because
    maxime> that would screw up my applications. However if I keep the load
    maxime> within a certain range I should fine, don't I ? I am synchronising
    maxime> one node to several public NTP servers, and the others nodes are
    maxime> synchronised to the first one. There are 2 to 24 nodes in my sub
    maxime> net. Do you think that should be feasible ?

    Please see:

    http://support.ntp.org/bin/view/Support/KnownOsIssues

    http://support.ntp.org/bin/view/Supp...HardwareIssues

    Aside from known problems with certain hardware and OS configurations, even
    under high load you should not see any problem with stepping time.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  7. Re: frequency adjusting only

    maxime louvel wrote:
    > Thanks for your answer,
    >
    > I can't have a step on the clock because that would screw up my
    > applications.
    > However if I keep the load within a certain range I should fine, don't I ?
    > I am synchronising one node to several public NTP servers, and the others
    > nodes are synchronised to the first one.
    > There are 2 to 24 nodes in my sub net.
    > Do you think that should be feasible ?
    >
    > Maxime


    You need at least 3 and preferably 4 public NTP servers in order for
    your local server to make decisions about which one is giving the most
    accurate and reliable time at any moment. 2 is not enough since there's
    no way to decide which is better. 3 allows 2 to gang up on the third.

    2-24 nodes is nothing. Even bombarding the NTP server with queries will
    barely be noticed. Don't forget at a minimum a node won't send a query
    more frequently than once every 64 seconds unless you are using a badly
    implemented NTP client.

    Danny

  8. Re: frequency adjusting only

    Thanks,

    I am actually using 4 public NTP server, which whom my node-1 synchronises
    to.
    Then node-1 broadcasts the time to all the other nodes in the subnet.

    My goal is to achieve a synchronisation between the nodes (not with the
    public NTP server) within 50 usec.
    I don't care if the synchronisation to the public NTP is accurate around
    half a second.
    I think it's possible, because the nodes are close to each other and every
    communication is using gigabit ethernet (cards + switch).

    I achieve to get a small offset when nothing else than linux and ntpd is
    running on the nodes
    (offset arount 10 usec).

    I have a program which sends data from one node to another.
    The sending/reception are timestamped and the delay is then computed.

    I would like the measured delay to be constrained in a 50usec wide range.

    Do you think it should be possible ?

    I have tried to run the test for 24h and didn't get the expected results.
    The range of the measured delay is 2 milliseconds (between -1ms and +1ms)
    with some spikes (ten or so for a milion measurments). The mean delay is
    -0.066087 (ms) and the std dev is 0.22849
    Do you think the spikes can influence ntp ?

    thanks very much

    Maxime

    On Tue, Apr 22, 2008 at 1:15 PM, Danny Mayer wrote:

    > maxime louvel wrote:
    >
    > > Thanks for your answer,
    > >
    > > I can't have a step on the clock because that would screw up my
    > > applications.
    > > However if I keep the load within a certain range I should fine, don't I
    > > ?
    > > I am synchronising one node to several public NTP servers, and the
    > > others
    > > nodes are synchronised to the first one.
    > > There are 2 to 24 nodes in my sub net.
    > > Do you think that should be feasible ?
    > >
    > > Maxime
    > >

    >
    > You need at least 3 and preferably 4 public NTP servers in order for your
    > local server to make decisions about which one is giving the most accurate
    > and reliable time at any moment. 2 is not enough since there's no way to
    > decide which is better. 3 allows 2 to gang up on the third.
    >
    > 2-24 nodes is nothing. Even bombarding the NTP server with queries will
    > barely be noticed. Don't forget at a minimum a node won't send a query more
    > frequently than once every 64 seconds unless you are using a badly
    > implemented NTP client.
    >
    > Danny
    >




    --
    Maxime Louvel
    0044 7964 5555 80
    43 Allen road
    Whitemore reans
    WV60AW Wolverhampton
    United Kingdom

  9. Re: frequency adjusting only

    On 2008-04-22, maxime louvel wrote:

    > My goal is to achieve a synchronisation between the nodes (not
    > with the public NTP server) within 50 usec.


    You may want to explore other synchronization options such as IRIG,
    distributed PPS, or a distributed 10MHz clock.

    >I don't care if the synchronisation to the public NTP is accurate
    >around half a second.


    You're displaying a common misconception about NTP.

    The goal of NTP is not explictly to synchronize clocks to "the one
    true time". Rather, NTP synchronizes clocks to a common time base. A
    "better" time base, and a "better" distribution method, allows tighter
    synchronization between nodes.

    It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    stable, and relatively inexpensive time base. A side effect of using UTC
    as your time base is that your clocks are synchronized to the correct
    time.

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

  10. Re: frequency adjusting only

    You might want to take a look at TSCclock developed at the University
    of Melbourne:

    http://www.cubinlab.ee.unimelb.edu.a...S07_camera.pdf

    Gene


  11. Re: frequency adjusting only

    On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:

    > On 2008-04-22, maxime louvel wrote:
    >
    > > My goal is to achieve a synchronisation between the nodes (not
    > > with the public NTP server) within 50 usec.

    >
    > You may want to explore other synchronization options such as IRIG,
    > distributed PPS, or a distributed 10MHz clock.



    Thanks I'm gonna look at some other synchronisation solution.

    >
    >
    > >I don't care if the synchronisation to the public NTP is accurate
    > >around half a second.

    >
    > You're displaying a common misconception about NTP.
    >
    > The goal of NTP is not explictly to synchronize clocks to "the one
    > true time". Rather, NTP synchronizes clocks to a common time base. A
    > "better" time base, and a "better" distribution method, allows tighter
    > synchronization between nodes.
    >
    > It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    > stable, and relatively inexpensive time base. A side effect of using UTC
    > as your time base is that your clocks are synchronized to the correct
    > time.



    Sorry I haven't express myself correctly. What I meant is that I want an
    accuracy of 50 usec within my subnet and I want my whole subnet to be
    synchronised to UTC with an accuracy of 1 second or less if possible.

    >
    >
    > --
    > Steve Kostecke
    > NTP Public Services Project - http://support.ntp.org/
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >




    --
    Maxime Louvel
    0044 7964 5555 80
    43 Allen road
    Whitemore reans
    WV60AW Wolverhampton
    United Kingdom

  12. Re: frequency adjusting only

    maxime louvel wrote:
    > On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:
    >
    >> On 2008-04-22, maxime louvel wrote:
    >>
    >>> My goal is to achieve a synchronisation between the nodes (not
    >>> with the public NTP server) within 50 usec.

    >> You may want to explore other synchronization options such as IRIG,
    >> distributed PPS, or a distributed 10MHz clock.

    >
    >
    > Thanks I'm gonna look at some other synchronisation solution.
    >
    >>
    >>> I don't care if the synchronisation to the public NTP is accurate
    >>> around half a second.

    >> You're displaying a common misconception about NTP.
    >>
    >> The goal of NTP is not explictly to synchronize clocks to "the one
    >> true time". Rather, NTP synchronizes clocks to a common time base. A
    >> "better" time base, and a "better" distribution method, allows tighter
    >> synchronization between nodes.
    >>
    >> It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    >> stable, and relatively inexpensive time base. A side effect of using UTC
    >> as your time base is that your clocks are synchronized to the correct
    >> time.

    >
    >
    > Sorry I haven't express myself correctly. What I meant is that I want an
    > accuracy of 50 usec within my subnet and I want my whole subnet to be
    > synchronised to UTC with an accuracy of 1 second or less if possible.


    That's going to be very difficult to do! Getting the whole herd to the
    point where the difference between any two nodes is less than 50 usec is
    damned near impossible using NTP on a LAN. You might want to consider
    using a Pulse Per Second (PPS) signal delivered to each node, with NTP
    used only to timestamp the rising edge. If you compensate for cable
    delays you can probably get to within 50-100 usec.

  13. Re: frequency adjusting only

    On 2008-04-22, maxime louvel wrote:

    > On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:
    >>
    >> >I don't care if the synchronisation to the public NTP is accurate
    >> >around half a second.

    >>
    >> You're displaying a common misconception about NTP.


    [snip]

    > Sorry I haven't express myself correctly. What I meant is that I want an
    > accuracy of 50 usec within my subnet and I want my whole subnet to be
    > synchronised to UTC with an accuracy of 1 second or less if possible.


    In my experience ...

    On a LAN ntpd shows an inter-node offset of between 2ms to 500us

    On The Internet ntpd shows an inter-node offset of between 10ms and 1ms

    YMMV

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

  14. Re: frequency adjusting only

    m.louvel@gmail.com (maxime louvel) writes:

    >Thanks,


    >I am actually using 4 public NTP server, which whom my node-1 synchronises
    >to.
    >Then node-1 broadcasts the time to all the other nodes in the subnet.


    >My goal is to achieve a synchronisation between the nodes (not with the
    >public NTP server) within 50 usec.


    That should be possible even with ntp. chrony will do a somewhat better
    job. On a "close" net like yours, the problem with ntp is that it does a
    poor job of tracking the frequency changes that come with the system's temp
    fluctuations because of doing variable amounts of work. chrony does a
    better job of that. But 50us should be possible with either.


    >I don't care if the synchronisation to the public NTP is accurate around
    >half a second.
    >I think it's possible, because the nodes are close to each other and every
    >communication is using gigabit ethernet (cards + switch).


    It is the latency not the speed of the switches that is important.


    >I achieve to get a small offset when nothing else than linux and ntpd is
    >running on the nodes
    >(offset arount 10 usec).


    >I have a program which sends data from one node to another.
    >The sending/reception are timestamped and the delay is then computed.


    >I would like the measured delay to be constrained in a 50usec wide range.


    YOu have NO control over the delay. That is in the switches.


    >Do you think it should be possible ?


    >I have tried to run the test for 24h and didn't get the expected results.
    >The range of the measured delay is 2 milliseconds (between -1ms and +1ms)
    >with some spikes (ten or so for a milion measurments). The mean delay is
    >-0.066087 (ms) and the std dev is 0.22849
    >Do you think the spikes can influence ntp ?


    It is designed to get rid of spikes.
    What in the world do you have on that net? That is bad behaviour on the
    part of the switches. Are they really that overloaded?



    >thanks very much


    >Maxime


    >On Tue, Apr 22, 2008 at 1:15 PM, Danny Mayer wrote:


    >> maxime louvel wrote:
    >>
    >> > Thanks for your answer,
    >> >
    >> > I can't have a step on the clock because that would screw up my
    >> > applications.
    >> > However if I keep the load within a certain range I should fine, don't I
    >> > ?
    >> > I am synchronising one node to several public NTP servers, and the
    >> > others
    >> > nodes are synchronised to the first one.
    >> > There are 2 to 24 nodes in my sub net.
    >> > Do you think that should be feasible ?
    >> >
    >> > Maxime
    >> >

    >>
    >> You need at least 3 and preferably 4 public NTP servers in order for your
    >> local server to make decisions about which one is giving the most accurate
    >> and reliable time at any moment. 2 is not enough since there's no way to
    >> decide which is better. 3 allows 2 to gang up on the third.
    >>
    >> 2-24 nodes is nothing. Even bombarding the NTP server with queries will
    >> barely be noticed. Don't forget at a minimum a node won't send a query more
    >> frequently than once every 64 seconds unless you are using a badly
    >> implemented NTP client.
    >>
    >> Danny
    >>




    >--
    >Maxime Louvel
    >0044 7964 5555 80
    >43 Allen road
    >Whitemore reans
    >WV60AW Wolverhampton
    >United Kingdom


  15. Re: frequency adjusting only

    m.louvel@gmail.com (maxime louvel) writes:

    >On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:


    >> On 2008-04-22, maxime louvel wrote:
    >>
    >> > My goal is to achieve a synchronisation between the nodes (not
    >> > with the public NTP server) within 50 usec.

    >>
    >> You may want to explore other synchronization options such as IRIG,
    >> distributed PPS, or a distributed 10MHz clock.



    >Thanks I'm gonna look at some other synchronisation solution.


    >>
    >>
    >> >I don't care if the synchronisation to the public NTP is accurate
    >> >around half a second.

    >>
    >> You're displaying a common misconception about NTP.
    >>
    >> The goal of NTP is not explictly to synchronize clocks to "the one
    >> true time". Rather, NTP synchronizes clocks to a common time base. A
    >> "better" time base, and a "better" distribution method, allows tighter
    >> synchronization between nodes.
    >>
    >> It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    >> stable, and relatively inexpensive time base. A side effect of using UTC
    >> as your time base is that your clocks are synchronized to the correct
    >> time.



    >Sorry I haven't express myself correctly. What I meant is that I want an
    >accuracy of 50 usec within my subnet and I want my whole subnet to be
    >synchronised to UTC with an accuracy of 1 second or less if possible.



    He is saying that ntp is designed to do the former, and if you include an
    external reference you get the latter for free. How badly overloaded are
    your switches?


    >>
    >>
    >> --
    >> Steve Kostecke
    >> NTP Public Services Project - http://support.ntp.org/
    >>
    >> _______________________________________________
    >> questions mailing list
    >> questions@lists.ntp.org
    >> https://lists.ntp.org/mailman/listinfo/questions
    >>




    >--
    >Maxime Louvel
    >0044 7964 5555 80
    >43 Allen road
    >Whitemore reans
    >WV60AW Wolverhampton
    >United Kingdom


  16. Re: frequency adjusting only

    "Richard B. Gilbert" writes:

    >maxime louvel wrote:
    >> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:
    >>
    >>> On 2008-04-22, maxime louvel wrote:
    >>>
    >>>> My goal is to achieve a synchronisation between the nodes (not
    >>>> with the public NTP server) within 50 usec.
    >>> You may want to explore other synchronization options such as IRIG,
    >>> distributed PPS, or a distributed 10MHz clock.

    >>
    >>
    >> Thanks I'm gonna look at some other synchronisation solution.
    >>
    >>>
    >>>> I don't care if the synchronisation to the public NTP is accurate
    >>>> around half a second.
    >>> You're displaying a common misconception about NTP.
    >>>
    >>> The goal of NTP is not explictly to synchronize clocks to "the one
    >>> true time". Rather, NTP synchronizes clocks to a common time base. A
    >>> "better" time base, and a "better" distribution method, allows tighter
    >>> synchronization between nodes.
    >>>
    >>> It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    >>> stable, and relatively inexpensive time base. A side effect of using UTC
    >>> as your time base is that your clocks are synchronized to the correct
    >>> time.

    >>
    >>
    >> Sorry I haven't express myself correctly. What I meant is that I want an
    >> accuracy of 50 usec within my subnet and I want my whole subnet to be
    >> synchronised to UTC with an accuracy of 1 second or less if possible.


    >That's going to be very difficult to do! Getting the whole herd to the
    >point where the difference between any two nodes is less than 50 usec is
    >damned near impossible using NTP on a LAN. You might want to consider
    >using a Pulse Per Second (PPS) signal delivered to each node, with NTP
    >used only to timestamp the rising edge. If you compensate for cable
    >delays you can probably get to within 50-100 usec.


    Nuts. I regularly get 10us on a lan connecting my machines all over the
    physics building here.
    The biggest problem is the rate changes due to heating while the computers
    are being used. The delay in the software adjusting to that is the key
    noise problem.


  17. Re: frequency adjusting only

    Hi

    thanks every body,
    I am looking at the other solution and see what's the best for me.

    - My switches shouldn't be overloaded but I have to check that.
    Any idea of how ? Network sniffing ? theory ?

    - I think I have a problem with the temperature, indeed I have let only ntpd
    run on the node for a week-end and the offset between the two cards was
    quite good. Then I have run my 24H script which has obviously increased the
    temperature.

    - I have understood that ntp should be able to manage what I want, but you
    seem divided on this issue

    Maxime


    On Tue, Apr 22, 2008 at 5:04 PM, Unruh wrote:

    > m.louvel@gmail.com (maxime louvel) writes:
    >
    > >On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:

    >
    > >> On 2008-04-22, maxime louvel wrote:
    > >>
    > >> > My goal is to achieve a synchronisation between the nodes (not
    > >> > with the public NTP server) within 50 usec.
    > >>
    > >> You may want to explore other synchronization options such as IRIG,
    > >> distributed PPS, or a distributed 10MHz clock.

    >
    >
    > >Thanks I'm gonna look at some other synchronisation solution.

    >
    > >>
    > >>
    > >> >I don't care if the synchronisation to the public NTP is accurate
    > >> >around half a second.
    > >>
    > >> You're displaying a common misconception about NTP.
    > >>
    > >> The goal of NTP is not explictly to synchronize clocks to "the one
    > >> true time". Rather, NTP synchronizes clocks to a common time base. A
    > >> "better" time base, and a "better" distribution method, allows tighter
    > >> synchronization between nodes.
    > >>
    > >> It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    > >> stable, and relatively inexpensive time base. A side effect of using

    > UTC
    > >> as your time base is that your clocks are synchronized to the correct
    > >> time.

    >
    >
    > >Sorry I haven't express myself correctly. What I meant is that I want an
    > >accuracy of 50 usec within my subnet and I want my whole subnet to be
    > >synchronised to UTC with an accuracy of 1 second or less if possible.

    >
    >
    > He is saying that ntp is designed to do the former, and if you include an
    > external reference you get the latter for free. How badly overloaded are
    > your switches?
    >
    >
    > >>
    > >>
    > >> --
    > >> Steve Kostecke
    > >> NTP Public Services Project - http://support.ntp.org/
    > >>
    > >> _______________________________________________
    > >> questions mailing list
    > >> questions@lists.ntp.org
    > >> https://lists.ntp.org/mailman/listinfo/questions
    > >>

    >
    >
    >
    > >--
    > >Maxime Louvel
    > >0044 7964 5555 80
    > >43 Allen road
    > >Whitemore reans
    > >WV60AW Wolverhampton
    > >United Kingdom

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




    --
    Maxime Louvel
    0044 7964 5555 80
    43 Allen road
    Whitemore reans
    WV60AW Wolverhampton
    United Kingdom

  18. Re: frequency adjusting only

    > If you compensate for cable
    >delays you can probably get to within 50-100 usec.


    Do the arithmetic. Cable delay is interesting for ns, not microseconds.

    The speed of light is 1 ft/ns. That's in vacuum. It's slower in cable.
    Inexpensive cable is about 1/2 c. Good cable is faster than that.
    The conversion from miles to km is about right. 5 microseconds
    per mile (in vacuum) is 5 microseconds per km in cable. So 100 meters
    would be 0.5 microsecond.

    So if we are discussing a handful of machines within ethernet/CAT5
    distances, you don't have to correct for cable lengths unless your
    target is better than a few microseconds.

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


  19. Re: frequency adjusting only


    >It is the latency not the speed of the switches that is important.


    You can correct for a fixed latency. What's nasty is variable
    latency.

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


  20. Re: frequency adjusting only

    Unruh wrote:
    > "Richard B. Gilbert" writes:
    >
    >> maxime louvel wrote:
    >>> On Tue, Apr 22, 2008 at 2:42 PM, Steve Kostecke wrote:
    >>>
    >>>> On 2008-04-22, maxime louvel wrote:
    >>>>
    >>>>> My goal is to achieve a synchronisation between the nodes (not
    >>>>> with the public NTP server) within 50 usec.
    >>>> You may want to explore other synchronization options such as IRIG,
    >>>> distributed PPS, or a distributed 10MHz clock.
    >>>
    >>> Thanks I'm gonna look at some other synchronisation solution.
    >>>
    >>>>> I don't care if the synchronisation to the public NTP is accurate
    >>>>> around half a second.
    >>>> You're displaying a common misconception about NTP.
    >>>>
    >>>> The goal of NTP is not explictly to synchronize clocks to "the one
    >>>> true time". Rather, NTP synchronizes clocks to a common time base. A
    >>>> "better" time base, and a "better" distribution method, allows tighter
    >>>> synchronization between nodes.
    >>>>
    >>>> It so happens that UTC (via GPS or HF Radio or UDP) is a ubiquitous,
    >>>> stable, and relatively inexpensive time base. A side effect of using UTC
    >>>> as your time base is that your clocks are synchronized to the correct
    >>>> time.
    >>>
    >>> Sorry I haven't express myself correctly. What I meant is that I want an
    >>> accuracy of 50 usec within my subnet and I want my whole subnet to be
    >>> synchronised to UTC with an accuracy of 1 second or less if possible.

    >
    >> That's going to be very difficult to do! Getting the whole herd to the
    >> point where the difference between any two nodes is less than 50 usec is
    >> damned near impossible using NTP on a LAN. You might want to consider
    >> using a Pulse Per Second (PPS) signal delivered to each node, with NTP
    >> used only to timestamp the rising edge. If you compensate for cable
    >> delays you can probably get to within 50-100 usec.

    >
    > Nuts. I regularly get 10us on a lan connecting my machines all over the
    > physics building here.
    > The biggest problem is the rate changes due to heating while the computers
    > are being used. The delay in the software adjusting to that is the key
    > noise problem.
    >


    A lot may depend on your LAN. A large 10/100 UTP net (300 nodes) in
    which traffic might pass through two or three switches to reach its
    destination is not necessarily well behaved for timing purposes. Even
    after dividing the mess into several VLANs the performance left much to
    be desired. It worked but I don't think we ever did much better than
    millisecond accuracy.

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