frequency adjusting only - NTP

This is a discussion on frequency adjusting only - NTP ; On Tue, Apr 22, 2008 at 9:39 AM, Richard B. Gilbert wrote: > 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 ...

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 94

Thread: frequency adjusting only

  1. Re: frequency adjusting only

    On Tue, Apr 22, 2008 at 9:39 AM, Richard B. Gilbert
    wrote:
    > 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.


    It likely depends on the LAN. What types of switches are in use? What
    NICs? What topology? What traffic? The more "enterprisey" brands,
    Cisco, Extreme, Foundry, Force10, HP, etc. typically have much better
    queuing behavior and much better latency characteristics. In network
    switches, you often actually get what you pay for in terms of
    performance and reliability. We use NETGEAR, Linksys, Dell, and other
    "value brand" switches for workstation access, and they have erratic
    performance characteristics, to put it mildly. Even though they are
    marketed as "enterprise-class" gear.

    If all the boxes in question had quality Intel NICs and were connected
    to the same lightly loaded Cisco 4948, I would guess that 50 Ás
    average offset might be achievable using NTP.

    --

    RPM

  2. Re: frequency adjusting only

    maxime louvel wrote:

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


    I think you can rule out using -x, then. 50 microseconds is pretty
    tight timing and basically requires that you use the kernel time
    discipline, as well as paying careful attention to system and network
    loading and interrupt latencies, both for timing and for the external
    events that you are timing.

    On the other hand, if you are tracking to 50 microseconds, you have a
    safety margin of over 200,000% before you risk a step.

    I would say forget about slew only mode and worry about fine timing.
    Also use a GPS clock with a PPS output on your primary server. I don't
    think it will be stable enough to ensure 50 microsecond lock for the
    network, when using an internet server, although using broadcast may
    help, as it may make the clients tend to wander together.


  3. Re: frequency adjusting only

    Steve Kostecke writes:

    >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


    ??? In my experience, on a Lan ntpd shows an internode offset of about 5-15
    usec, and on the internet (ADSL) an offset of about 200usec.



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


  4. Re: frequency adjusting only

    On 2008-04-22, Unruh wrote:

    > Steve Kostecke writes:
    >
    > ??? In my experience, on a Lan ntpd shows an internode offset of about
    > 5-15 usec, and on the internet (ADSL) an offset of about 200usec.


    Here's an aggregated plot of the node offsets on my LAN over the last 24
    hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.

    http://support.ntp.org/bin/viewfile/...an_offsets.png

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

  5. Re: frequency adjusting only

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

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


    Look at the ntp roundtrip times and see how they fluctuate. (peerstats)


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


    ntp is designed to take hours to respond to frequency changes. Clearly if
    your machine's temp fluctuates on the time scale of hours that will be
    problematic.


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


    I think from my own experiments that it should.

    As I said chrony will give you a factor of 2 better control (30us rather
    than 60us say) if the computers have temp fluctuations. If the rates of all
    computers never changes, chrony will average out the random "phase
    fluctutions" better as well .
    But either should work.




    >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


  6. Re: frequency adjusting only

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

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


    Since the cable delay is symmetric, ntp will compensate anyway, no matter
    how long the cable. Only if the cable is asymmetric( cable one way,
    passenger pigeon the other) is there a problem.


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



  7. Re: frequency adjusting only

    "Richard B. Gilbert" writes:

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


    Well, I am in a physics dept. Some of my machines are across the building
    from others-- into the hall switch cabinette down to the basement over to
    the uplink to the other cabinette, through those switches to the other
    computer. Typical fluctuation in timing is less than 20us, much less.
    http://www.theory.physics.ubc.ca/chrony/chrony.html

    inflaton, orbit, dilaton are across the building from string, the GPS
    controlled ntp time source. The rest are in the same room.(but the switch
    is across the hall.)





  8. Re: frequency adjusting only

    Steve Kostecke writes:

    >On 2008-04-22, Unruh wrote:


    >> Steve Kostecke writes:
    >>
    >> ??? In my experience, on a Lan ntpd shows an internode offset of about
    >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.


    >Here's an aggregated plot of the node offsets on my LAN over the last 24
    >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.


    >http://support.ntp.org/bin/viewfile/...an_offsets.png


    I agree those are pretty bad. HOw are they hooked up? It looks like one of
    the hops is via a telephone modem!

    See www.theory.physics/chrony/chrony.html
    Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan and
    ntp server, and I'll do what I want to.)


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


  9. Re: frequency adjusting only

    Hi,

    - my network contains only one switch, and all the node are in the same
    room.
    Thus I don't think cabling is a problem. I still have to check the latency
    of the switch.

    - I can't use a GPS or other material. I though I wouldn't need any because
    I don't won't a great accuracy with the real time, just between my nodes. I
    also think it would have been easier and better to have a common high
    precision time source (GPS)... But I can't afford that

    Do you have an explanation of the so different performances observed in your
    NTP synchronisations ?

    - I'm going to look at chrony, which at first glance seems usable in my
    case.

    - I am already using the -x option, to be certain to avoid any step.

    Maxime

    On Wed, Apr 23, 2008 at 2:10 AM, Unruh wrote:

    > Steve Kostecke writes:
    >
    > >On 2008-04-22, Unruh wrote:

    >
    > >> Steve Kostecke writes:
    > >>
    > >> ??? In my experience, on a Lan ntpd shows an internode offset of about
    > >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.

    >
    > >Here's an aggregated plot of the node offsets on my LAN over the last 24
    > >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.

    >
    > >

    > http://support.ntp.org/bin/viewfile/...an_offsets.png
    >
    > I agree those are pretty bad. HOw are they hooked up? It looks like one of
    > the hops is via a telephone modem!
    >
    > See www.theory.physics/chrony/chrony.html
    > Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan and
    > ntp server, and I'll do what I want to.)
    >
    >
    > >--
    > >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

  10. question on ntp burst

    Hi

    Could someone help me understand behaviour of burst post and pre sync. Does
    burst works after the system is in sync ?

    Will burst option be sending 8 packets even after it gets synced.

    if (peer->flags & FLAG_BURST &&
    peer_unfit(peer))
    peer->burst = NTP_BURST;


    Regards

    RR

  11. Re: frequency adjusting only

    HI again,

    I am thinking that NTP should behave correctly if the activity on the nodes
    (small temperature, hence frequency variation) and on the network (small
    latency of the switch) are roughly constant.
    But if not it will have some trouble, either to compensate the frequency
    change or to deal with the network delay latency.

    what do you think ?

    thanks,

    Maxime

    On Wed, Apr 23, 2008 at 7:12 AM, maxime louvel wrote:

    > Hi,
    >
    > - my network contains only one switch, and all the node are in the same
    > room.
    > Thus I don't think cabling is a problem. I still have to check the latency
    > of the switch.
    >
    > - I can't use a GPS or other material. I though I wouldn't need any
    > because I don't won't a great accuracy with the real time, just between my
    > nodes. I also think it would have been easier and better to have a common
    > high precision time source (GPS)... But I can't afford that
    >
    > Do you have an explanation of the so different performances observed in
    > your NTP synchronisations ?
    >
    > - I'm going to look at chrony, which at first glance seems usable in my
    > case.
    >
    > - I am already using the -x option, to be certain to avoid any step.
    >
    > Maxime
    >
    >
    > On Wed, Apr 23, 2008 at 2:10 AM, Unruh wrote:
    >
    > > Steve Kostecke writes:
    > >
    > > >On 2008-04-22, Unruh wrote:

    > >
    > > >> Steve Kostecke writes:
    > > >>
    > > >> ??? In my experience, on a Lan ntpd shows an internode offset of

    > > about
    > > >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.

    > >
    > > >Here's an aggregated plot of the node offsets on my LAN over the last

    > > 24
    > > >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.

    > >
    > > >

    > > http://support.ntp.org/bin/viewfile/...an_offsets.png
    > >
    > > I agree those are pretty bad. HOw are they hooked up? It looks like one
    > > of
    > > the hops is via a telephone modem!
    > >
    > > See www.theory.physics/chrony/chrony.html
    > > Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan and
    > > ntp server, and I'll do what I want to.)
    > >
    > >
    > > >--
    > > >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
    >




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

  12. Re: frequency adjusting only

    I have checked the roundtrip delay with ntpq -p.
    It seems that I always have 0.147 ms.
    But I haven't monitored it properly, just each time I ran the command I got
    this value

    On Wed, Apr 23, 2008 at 7:30 AM, maxime louvel wrote:

    > HI again,
    >
    > I am thinking that NTP should behave correctly if the activity on the
    > nodes (small temperature, hence frequency variation) and on the network
    > (small latency of the switch) are roughly constant.
    > But if not it will have some trouble, either to compensate the frequency
    > change or to deal with the network delay latency.
    >
    > what do you think ?
    >
    > thanks,
    >
    > Maxime
    >
    >
    > On Wed, Apr 23, 2008 at 7:12 AM, maxime louvel wrote:
    >
    > > Hi,
    > >
    > > - my network contains only one switch, and all the node are in the same
    > > room.
    > > Thus I don't think cabling is a problem. I still have to check the
    > > latency of the switch.
    > >
    > > - I can't use a GPS or other material. I though I wouldn't need any
    > > because I don't won't a great accuracy with the real time, just between my
    > > nodes. I also think it would have been easier and better to have a common
    > > high precision time source (GPS)... But I can't afford that
    > >
    > > Do you have an explanation of the so different performances observed in
    > > your NTP synchronisations ?
    > >
    > > - I'm going to look at chrony, which at first glance seems usable in my
    > > case.
    > >
    > > - I am already using the -x option, to be certain to avoid any step.
    > >
    > > Maxime
    > >
    > >
    > > On Wed, Apr 23, 2008 at 2:10 AM, Unruh
    > > wrote:
    > >
    > > > Steve Kostecke writes:
    > > >
    > > > >On 2008-04-22, Unruh wrote:
    > > >
    > > > >> Steve Kostecke writes:
    > > > >>
    > > > >> ??? In my experience, on a Lan ntpd shows an internode offset of
    > > > about
    > > > >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.
    > > >
    > > > >Here's an aggregated plot of the node offsets on my LAN over the last
    > > > 24
    > > > >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.
    > > >
    > > > >
    > > > http://support.ntp.org/bin/viewfile/...an_offsets.png
    > > >
    > > > I agree those are pretty bad. HOw are they hooked up? It looks like
    > > > one of
    > > > the hops is via a telephone modem!
    > > >
    > > > See www.theory.physics/chrony/chrony.html
    > > > Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan
    > > > and
    > > > ntp server, and I'll do what I want to.)
    > > >
    > > >
    > > > >--
    > > > >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
    > >

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




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

  13. Re: frequency adjusting only

    maxime louvel wrote:
    > Hi,
    >
    > - my network contains only one switch, and all the node are in the same
    > room.
    > Thus I don't think cabling is a problem. I still have to check the latency
    > of the switch.
    >
    > - I can't use a GPS or other material. I though I wouldn't need any because
    > I don't won't a great accuracy with the real time, just between my nodes. I
    > also think it would have been easier and better to have a common high
    > precision time source (GPS)... But I can't afford that
    >

    A GPS timing receiver can be purchased for less than $100 US! (Garmin
    GPS 18LVC). You must be able to site an antenna where it will have an
    unobstructed view of the sky.

    Having an ultra stable source of time, such as a GPS receiver has a
    noticeable effect on the closeness of the synchronization you can achieve.



  14. Re: frequency adjusting only

    maxime louvel wrote:
    > 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.
    >


    If you are using broadcast mode then you have two additional issues that
    you need to deal with:

    1) authentication is required by default
    2) you are not measuring the delay for every packet

    With autokey, the delay gets measured during the autokey dance which
    happens in client/server mode and then it switches to broadcast when it
    completes. You cannot measure the delay in broadcast mode since the
    server sends out the packets and the client just receives them.
    Broadcast can only apply the delay estimates that it got when in the
    autokey dance and cannot account for changes until the next autokey dance.

    If accuracy is critical in this environment, don't use broadcast. At
    least in client/server mode you get to measure the delay with each packet.

    Danny


    > 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


  15. Re: frequency adjusting only

    - The decision of buying a GPS is not mine ...
    So let's say for now that's still not possible, if no other solution is
    found I'll conclude that a GPS has to be bought.

    - Danny, you're talking about the delay I got with ntpq -p ?

    - I have chosen a broadcast configuration for two reasons :
    - easier to install
    - I am doing the tests on only 2 nodes, thus with broadcast I assumed that
    more nodes won't change the accuracy

    I though it was possible to achieve the same precision with broadcast than
    with C/S, that's erroneous ?

    maxime

    On Wed, Apr 23, 2008 at 12:42 PM, Danny Mayer wrote:

    > maxime louvel wrote:
    >
    > > 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.
    > >
    > >

    > If you are using broadcast mode then you have two additional issues that
    > you need to deal with:
    >
    > 1) authentication is required by default
    > 2) you are not measuring the delay for every packet
    >
    > With autokey, the delay gets measured during the autokey dance which
    > happens in client/server mode and then it switches to broadcast when it
    > completes. You cannot measure the delay in broadcast mode since the server
    > sends out the packets and the client just receives them. Broadcast can only
    > apply the delay estimates that it got when in the autokey dance and cannot
    > account for changes until the next autokey dance.
    >
    > If accuracy is critical in this environment, don't use broadcast. At least
    > in client/server mode you get to measure the delay with each packet.
    >
    > Danny
    >
    >
    >
    > 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
    > >

    >



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

  16. Re: frequency adjusting only

    On 2008-04-23, Unruh wrote:

    > Steve Kostecke writes:
    >
    >>Here's an aggregated plot of the node offsets on my LAN over the
    >>last 24 hours. I see +3/-5 milliseconds, not anything near 5-15
    >>microseconds.


    [snip: URL for plot]

    > I agree those are pretty bad.


    I said nothing about it being bad. In fact, it's good enough for my
    needs.

    > How are they hooked up? It looks like one of the hops is via a
    > telephone modem!


    All of the systems are in the same building on a fast ethernet LAN with
    a D-Link Switch.

    > See www.theory.physics/chrony/chrony.html


    That hostname does not resolve for me.

    I use this group of systems to test different ntpd configurations, so
    other software is out of the question.

    At the moment these systems are configured in a Manycast Orphan mesh
    (i.e. each system has orphan mode enabled and is a Manycast client and
    server). Ntp0 (green plot) also has a CHU ref-clock. Rover (red plot) is
    also configured with a good number of remote time servers.

    > Its my lan and ntp server, and I'll do what I want to.


    Likewise.

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

  17. Re: frequency adjusting only

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

    >Hi,


    >- my network contains only one switch, and all the node are in the same
    >room.
    >Thus I don't think cabling is a problem. I still have to check the latency
    >of the switch.


    >- I can't use a GPS or other material. I though I wouldn't need any because
    >I don't won't a great accuracy with the real time, just between my nodes. I
    >also think it would have been easier and better to have a common high
    >precision time source (GPS)... But I can't afford that


    A garmin 18LVM is about $60. That is all you need plus a bit of soldering
    so as to put on the approriate plugs.


    >Do you have an explanation of the so different performances observed in your
    >NTP synchronisations ?


    Nope. All I can tell you is what I see. Maybe we have better switches here.



    >- I'm going to look at chrony, which at first glance seems usable in my
    >case.


    >- I am already using the -x option, to be certain to avoid any step.


    >Maxime


    >On Wed, Apr 23, 2008 at 2:10 AM, Unruh wrote:


    >> Steve Kostecke writes:
    >>
    >> >On 2008-04-22, Unruh wrote:

    >>
    >> >> Steve Kostecke writes:
    >> >>
    >> >> ??? In my experience, on a Lan ntpd shows an internode offset of about
    >> >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.

    >>
    >> >Here's an aggregated plot of the node offsets on my LAN over the last 24
    >> >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.

    >>
    >> >

    >> http://support.ntp.org/bin/viewfile/...an_offsets.png
    >>
    >> I agree those are pretty bad. HOw are they hooked up? It looks like one of
    >> the hops is via a telephone modem!
    >>
    >> See www.theory.physics/chrony/chrony.html
    >> Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan and
    >> ntp server, and I'll do what I want to.)
    >>
    >>
    >> >--
    >> >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


  18. Re: frequency adjusting only

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

    >HI again,


    >I am thinking that NTP should behave correctly if the activity on the nodes
    >(small temperature, hence frequency variation) and on the network (small
    >latency of the switch) are roughly constant.
    >But if not it will have some trouble, either to compensate the frequency
    >change or to deal with the network delay latency.


    ntp always behaves correctly. It is a stable system. It is not optimised to
    get the very best behaviour is all. Part of its stability is its long
    integration times ( and its throwing away 80% of the data in the clock
    filter to try to beat down transport noise.)
    Even if the frequencies change, it works well, just not as well as it
    could. (Or perhaps the chrony philosopy has some situations where it fails.
    I do not know)


    >what do you think ?


    >thanks,


    >Maxime


    >On Wed, Apr 23, 2008 at 7:12 AM, maxime louvel wrote:


    >> Hi,
    >>
    >> - my network contains only one switch, and all the node are in the same
    >> room.
    >> Thus I don't think cabling is a problem. I still have to check the latency
    >> of the switch.
    >>
    >> - I can't use a GPS or other material. I though I wouldn't need any
    >> because I don't won't a great accuracy with the real time, just between my
    >> nodes. I also think it would have been easier and better to have a common
    >> high precision time source (GPS)... But I can't afford that
    >>
    >> Do you have an explanation of the so different performances observed in
    >> your NTP synchronisations ?
    >>
    >> - I'm going to look at chrony, which at first glance seems usable in my
    >> case.
    >>
    >> - I am already using the -x option, to be certain to avoid any step.
    >>
    >> Maxime
    >>
    >>
    >> On Wed, Apr 23, 2008 at 2:10 AM, Unruh wrote:
    >>
    >> > Steve Kostecke writes:
    >> >
    >> > >On 2008-04-22, Unruh wrote:
    >> >
    >> > >> Steve Kostecke writes:
    >> > >>
    >> > >> ??? In my experience, on a Lan ntpd shows an internode offset of
    >> > about
    >> > >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.
    >> >
    >> > >Here's an aggregated plot of the node offsets on my LAN over the last
    >> > 24
    >> > >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.
    >> >
    >> > >
    >> > http://support.ntp.org/bin/viewfile/...an_offsets.png
    >> >
    >> > I agree those are pretty bad. HOw are they hooked up? It looks like one
    >> > of
    >> > the hops is via a telephone modem!
    >> >
    >> > See www.theory.physics/chrony/chrony.html
    >> > Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan and
    >> > ntp server, and I'll do what I want to.)
    >> >
    >> >
    >> > >--
    >> > >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
    >>




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


  19. Re: frequency adjusting only

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

    >I have checked the roundtrip delay with ntpq -p.
    >It seems that I always have 0.147 ms.
    >But I haven't monitored it properly, just each time I ran the command I got
    >this value


    Yes. Mine are around 200us (.2ms)


    >On Wed, Apr 23, 2008 at 7:30 AM, maxime louvel wrote:


    >> HI again,
    >>
    >> I am thinking that NTP should behave correctly if the activity on the
    >> nodes (small temperature, hence frequency variation) and on the network
    >> (small latency of the switch) are roughly constant.
    >> But if not it will have some trouble, either to compensate the frequency
    >> change or to deal with the network delay latency.
    >>
    >> what do you think ?
    >>
    >> thanks,
    >>
    >> Maxime
    >>
    >>
    >> On Wed, Apr 23, 2008 at 7:12 AM, maxime louvel wrote:
    >>
    >> > Hi,
    >> >
    >> > - my network contains only one switch, and all the node are in the same
    >> > room.
    >> > Thus I don't think cabling is a problem. I still have to check the
    >> > latency of the switch.
    >> >
    >> > - I can't use a GPS or other material. I though I wouldn't need any
    >> > because I don't won't a great accuracy with the real time, just between my
    >> > nodes. I also think it would have been easier and better to have a common
    >> > high precision time source (GPS)... But I can't afford that
    >> >
    >> > Do you have an explanation of the so different performances observed in
    >> > your NTP synchronisations ?
    >> >
    >> > - I'm going to look at chrony, which at first glance seems usable in my
    >> > case.
    >> >
    >> > - I am already using the -x option, to be certain to avoid any step.
    >> >
    >> > Maxime
    >> >
    >> >
    >> > On Wed, Apr 23, 2008 at 2:10 AM, Unruh
    >> > wrote:
    >> >
    >> > > Steve Kostecke writes:
    >> > >
    >> > > >On 2008-04-22, Unruh wrote:
    >> > >
    >> > > >> Steve Kostecke writes:
    >> > > >>
    >> > > >> ??? In my experience, on a Lan ntpd shows an internode offset of
    >> > > about
    >> > > >> 5-15 usec, and on the internet (ADSL) an offset of about 200usec.
    >> > >
    >> > > >Here's an aggregated plot of the node offsets on my LAN over the last
    >> > > 24
    >> > > >hours. I see +3/-5 milliseconds, not anything near 5-15 microseconds.
    >> > >
    >> > > >
    >> > > http://support.ntp.org/bin/viewfile/...an_offsets.png
    >> > >
    >> > > I agree those are pretty bad. HOw are they hooked up? It looks like
    >> > > one of
    >> > > the hops is via a telephone modem!
    >> > >
    >> > > See www.theory.physics/chrony/chrony.html
    >> > > Mind you those are running with maxpoll 7 not maxpoll 10 (Its my lan
    >> > > and
    >> > > ntp server, and I'll do what I want to.)
    >> > >
    >> > >
    >> > > >--
    >> > > >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
    >> >

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




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


  20. Re: frequency adjusting only

    Steve Kostecke writes:

    >On 2008-04-23, Unruh wrote:



    >> See www.theory.physics/chrony/chrony.html


    >That hostname does not resolve for me.


    OOps. Fingers faster than brain
    www.theory.physics.ubc.ca/chrony/chrony.html


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