frequency adjusting only - NTP

This is a discussion on frequency adjusting only - NTP ; On 2008-04-23, maxime louvel wrote: > 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 ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 94

Thread: frequency adjusting only

  1. Re: frequency adjusting only

    On 2008-04-23, maxime louvel wrote:

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


    I find it curious to hear people say that time stability is critical
    to the functioning of their application/business/whatever and then, in
    the next breath, say that they can't afford the requisite sub-$1000
    solution.

    > - I have chosen a broadcast configuration for two reasons :
    > - easier to install


    The configuration for a leaf-node which polls a local time server is
    arguably simpler than any *cast configuration.

    > - I am doing the tests on only 2 nodes, thus with broadcast I assumed that
    > more nodes won't change the accuracy


    A broadcast client calculates the delay correction from the server
    during the intial unicast (i.e. client/server) phase of the association.
    This delay correction is based on the network conditions at the time
    the association is started. Broadcast packets sent during periods of
    lighter, or heavier, network congestion/loading will receive a less than
    correct broadcast delay correction.

    One big advantage to unicast assciations is that each poll automatically
    compenstates for the current network conditions.

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

  2. Re: frequency adjusting only

    maxime louvel wrote:
    > - 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 haven't seen what your delays are but if that's for the server
    providing the broadcast packets that's a different delay. You need to be
    doing queries of each of the clients to which you are distributing time
    packets.

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


    No because you are not continuously monitoring the delay. If you are not
    using authentication (and you haven't said one way or the other) then
    the client doesn't even get an initial estimate of the delay. At that
    point if you are only receiving packets you don't even have an idea of
    the delay. If you are interested in correcting for the delay you have to
    have a way of measuring it. NTP can do that but only if you are using
    standard server configuration or with broadcast using authentication.
    The only other way to account for the delay is to estimate it for each
    node and add it into the configuration file with, I believe, the fudge
    command, but you'd have to look that up.

    The most accurate way keep all your nodes closely synchronized without
    using refclocks is to use client/server mode since that will be
    continuously monitoring the delay.

    Danny
    > maxime


  3. Re: frequency adjusting only

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


    As others have pointed out, your timing requirements are rather more
    than run of the mill, so you should expect to have to pay to meet them.
    You may need to take special consideration of not just the time
    distribution network, but also the time characteristics of the
    application and the application hardware.

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


    Your biggest problem is that the DCF machine isn't synchronised; it is
    free running, probably with a frequency error of 10s of parts per
    million and is occasionally violently reset. On the other hand, it is
    claiming to be synchronised to quite a high level of accuracy.

    If you can't use GPS and PPS to get a stable master server, you should
    not use any source of UTC at all. Simply calibrate the drift file on
    the master (so that you get a full +/- 500ppm tolerance for the other
    machines, and run it with only the local clock as source.

    However, depending on the quality of your network, you may need to
    provide a common 1PPS feed to all the machines. I'm not sure it is
    possible to do this with the local clock as the master clock on one
    machine, so you may need to make some code changes.

    You should allow time steps, as not allowing them tends to disable the
    kernel time discipline, which you will need for very accurate clock
    tracking.


  4. Re: frequency adjusting only

    On Thu, Apr 24, 2008 at 11:27 PM, David Woolley
    wrote:

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

    >
    > As others have pointed out, your timing requirements are rather more
    > than run of the mill, so you should expect to have to pay to meet them.
    > You may need to take special consideration of not just the time
    > distribution network, but also the time characteristics of the
    > application and the application hardware.
    >


    I actually don't really understand why a GPS would improve my
    synchronisation.
    Indeed I can't have a GPS to all the nodes (no connectivity possible). My
    nodes are actually embedded cards. They run linux have have some pretty good
    features for embedded platforms. But still the available connectivity is
    limited.
    Thus if I use a GPS it would be connected to a server in the same subnet and
    my nodes will then synchronise to it. Thus why should I get a better
    accuracy between my node than I already have ? The network and the nodes
    latency won't be improve.

    Unless if the GPS allow my server to be more stable and thus I can assume to
    get a better synchronisation...

    >
    > >
    > > Do you have an explanation of the so different performances observed in

    > your
    > > NTP synchronisations ?

    >
    > Your biggest problem is that the DCF machine isn't synchronised; it is
    > free running, probably with a frequency error of 10s of parts per
    > million and is occasionally violently reset. On the other hand, it is
    > claiming to be synchronised to quite a high level of accuracy.
    >
    > If you can't use GPS and PPS to get a stable master server, you should
    > not use any source of UTC at all. Simply calibrate the drift file on
    > the master (so that you get a full +/- 500ppm tolerance for the other
    > machines, and run it with only the local clock as source.
    >
    > However, depending on the quality of your network, you may need to
    > provide a common 1PPS feed to all the machines. I'm not sure it is
    > possible to do this with the local clock as the master clock on one
    > machine, so you may need to make some code changes.
    >
    > You should allow time steps, as not allowing them tends to disable the
    > kernel time discipline, which you will need for very accurate clock
    > tracking.
    >


    - I have to keep my nodes synchronised to real time, for several reason:
    they use NFS, they interact with the outside world.
    - I can't have any clock step, because I have some application that assume
    there is no one. If clock steps occur, my applications will be screwed up.


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

  5. Re: frequency adjusting only

    maxime louvel wrote:

    > Unless if the GPS allow my server to be more stable and thus I can assume to
    > get a better synchronisation...


    Firstly, I got two threads confused, so some of my comments weren't
    based on your situation. In particular, the unsynchronised DCF system
    relates to the other thread.

    A node synchronized to GPS *with PPS* will be much more stable than a
    system that is free-running or synchronised by other typical means.

  6. Re: frequency adjusting only

    On Fri, Apr 25, 2008 at 8:14 AM, David Woolley
    wrote:

    > maxime louvel wrote:
    >
    > > Unless if the GPS allow my server to be more stable and thus I can assume

    > to
    > > get a better synchronisation...

    >
    > Firstly, I got two threads confused, so some of my comments weren't
    > based on your situation. In particular, the unsynchronised DCF system
    > relates to the other thread.
    >


    No pb


    >
    > A node synchronized to GPS *with PPS* will be much more stable than a
    > system that is free-running or synchronised by other typical means.
    >


    Ok , thus I should have a better accuracy for the nodes synchronised to
    this server than for the nodes synchronised to server itself synchronised
    through internet to a stratum 2.
    But that still doesn't solve the problem I encounter in my subnet, does it ?

    If no, the only solution would be that each node gets a PPS signal via its
    serial line ??

    thanks

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

  7. Re: frequency adjusting only

    On Fri, Apr 25, 2008 at 2:35 AM, maxime louvel wrote:

    > Ok , thus I should have a better accuracy for the nodes synchronised to
    > this server than for the nodes synchronised to server itself synchronised
    > through internet to a stratum 2.
    > But that still doesn't solve the problem I encounter in my subnet, does it ?
    >

    Just thought of something... are any of these virtual machines or
    blade servers? If virtual machines, you will *never* get reasonable
    time on them because of shared interrupts. That's just one of the
    trade-offs with VMs. The best we've seen is about 50ms average offset
    in VMs on lightly loaded hosts.

    If they are blade servers, they may also very well have a shared
    netoworking architecture that causes the behavior you are seeing.
    --
    RPM

  8. Re: frequency adjusting only

    David Woolley writes:

    >maxime louvel wrote:


    >> Unless if the GPS allow my server to be more stable and thus I can assume to
    >> get a better synchronisation...


    >Firstly, I got two threads confused, so some of my comments weren't
    >based on your situation. In particular, the unsynchronised DCF system
    >relates to the other thread.


    >A node synchronized to GPS *with PPS* will be much more stable than a
    >system that is free-running or synchronised by other typical means.


    I do not know that it is more stable. It does keep better time.


  9. Re: frequency adjusting only

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

    >On Fri, Apr 25, 2008 at 8:14 AM, David Woolley
    > wrote:



    >>
    >> A node synchronized to GPS *with PPS* will be much more stable than a
    >> system that is free-running or synchronised by other typical means.
    >>


    >Ok , thus I should have a better accuracy for the nodes synchronised to
    >this server than for the nodes synchronised to server itself synchronised
    >through internet to a stratum 2.
    >But that still doesn't solve the problem I encounter in my subnet, does it ?


    >If no, the only solution would be that each node gets a PPS signal via its
    >serial line ??


    As I said, I have no idea why your jitter is so large. I get about 10us The
    network cards are standard run of the mill ( and various) network cards.
    The switches are Cisco gigabit switches.
    I do use chrony, rather than ntp.
    You may wnat to make sure that your ntp run at high priority



    >thanks


    >>
    >> _______________________________________________
    >> 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. Re: frequency adjusting only

    - I am running ntp at max priority (ntpd -N)

    - My nodes are real machines, not VM

    - I haven't tried chrony yet, but I probably will.


    On Fri, Apr 25, 2008 at 3:29 PM, Unruh wrote:

    > m.louvel@gmail.com (maxime louvel) writes:
    >
    > >On Fri, Apr 25, 2008 at 8:14 AM, David Woolley
    > > wrote:

    >
    >
    > >>
    > >> A node synchronized to GPS *with PPS* will be much more stable than a
    > >> system that is free-running or synchronised by other typical means.
    > >>

    >
    > >Ok , thus I should have a better accuracy for the nodes synchronised to
    > >this server than for the nodes synchronised to server itself synchronised
    > >through internet to a stratum 2.
    > >But that still doesn't solve the problem I encounter in my subnet, does it

    > ?
    >
    > >If no, the only solution would be that each node gets a PPS signal via its
    > >serial line ??

    >
    > As I said, I have no idea why your jitter is so large. I get about 10us The
    > network cards are standard run of the mill ( and various) network cards.
    > The switches are Cisco gigabit switches.
    > I do use chrony, rather than ntp.
    > You may wnat to make sure that your ntp run at high priority
    >
    >
    >
    > >thanks

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

  11. Re: frequency adjusting only


    >I actually don't really understand why a GPS would improve my
    >synchronisation.


    If your master server has GPS, its time will be more stable.
    That means your clients can sync to a stable clock rather than
    trying to track a clock that is wobbling around. (Things
    are simpler and work better when there is less noise in the system.)

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


  12. Re: frequency adjusting only


    >- I have to keep my nodes synchronised to real time, for several reason:
    >they use NFS, they interact with the outside world.


    I think your initial goal was synchronization to 10 microseconds.

    Do you really need that for NFS? (Do file times include the fractions
    of a second?)

    Most interaction with the outside world is via a network connection.
    Is some box out there really going to be able to tell if your
    clock is off by 10 microseconds? (Hint: If so, keeping clocks
    synchronized would be much easier.)

    >- I can't have any clock step, because I have some application that assume
    >there is no one. If clock steps occur, my applications will be screwed up.


    It may be simpler to fix your application than to keep clocks
    from going backwards.

    What will happen if time does go backwards? How are you going to
    recover if something screws up and your time gets set ahead by an
    hour, a day, or a year, and then runs for a while?

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


  13. Re: frequency adjusting only

    - 10 usec is of course not for NFS, but I am also using NFS (no other
    choice) and that was just an example to tell that I need to keep my nodes
    synchronised to real time, not just between them

    - I have no idea if the applications can be fixed, as they are not mine and
    I'm not in charge of them

    On Fri, Apr 25, 2008 at 9:30 PM, Hal Murray <
    hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

    >
    > >I actually don't really understand why a GPS would improve my
    > >synchronisation.

    >
    > If your master server has GPS, its time will be more stable.
    > That means your clients can sync to a stable clock rather than
    > trying to track a clock that is wobbling around. (Things
    > are simpler and work better when there is less noise in the system.)
    >


    OK thanks.

    >
    > --
    > These are my opinions, not necessarily my employer's. I hate spam.
    >
    > _______________________________________________
    > 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

  14. Re: frequency adjusting only

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

    >- 10 usec is of course not for NFS, but I am also using NFS (no other
    >choice) and that was just an example to tell that I need to keep my nodes
    >synchronised to real time, not just between them


    There isnothing within any OS that is sensitive to time on us level.
    There s nothing in any program or operating ssytem that is sensitive to the
    system being off real time.


    >- I have no idea if the applications can be fixed, as they are not mine and
    >I'm not in charge of them


    >On Fri, Apr 25, 2008 at 9:30 PM, Hal Murray <
    >hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:


    >>
    >> >I actually don't really understand why a GPS would improve my
    >> >synchronisation.

    >>
    >> If your master server has GPS, its time will be more stable.
    >> That means your clients can sync to a stable clock rather than
    >> trying to track a clock that is wobbling around. (Things
    >> are simpler and work better when there is less noise in the system.)
    >>


  15. Re: frequency adjusting only

    maxime louvel wrote:
    > - 10 usec is of course not for NFS, but I am also using NFS (no other
    > choice) and that was just an example to tell that I need to keep my nodes
    > synchronised to real time, not just between them
    >
    > - I have no idea if the applications can be fixed, as they are not mine and
    > I'm not in charge of them
    >


    Can you at least tell us what they are doing that require such
    synchronization? Without giving away any secrets of course. What is the
    risks if the clock steps back or forward? It's extreme rare after the
    first synchronization especially if these systems are on a LAN.

    Danny

  16. Re: frequency adjusting only

    On Sun, Apr 27, 2008 at 4:01 AM, Danny Mayer wrote:

    > maxime louvel wrote:
    >
    > > - 10 usec is of course not for NFS, but I am also using NFS (no other
    > > choice) and that was just an example to tell that I need to keep my
    > > nodes
    > > synchronised to real time, not just between them
    > >
    > > - I have no idea if the applications can be fixed, as they are not mine
    > > and
    > > I'm not in charge of them
    > >
    > >

    > Can you at least tell us what they are doing that require such
    > synchronization? Without giving away any secrets of course. What is the
    > risks if the clock steps back or forward? It's extreme rare after the first
    > synchronization especially if these systems are on a LAN.



    Sorry it's actually difficult for me to precise this topic for
    confidentiality reason of course and also because I'm an intern and thus
    there for a short period. Hence I don't know exactly why myself. This is
    just one of the requirement of my project.

    >
    >
    > Danny
    >




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

  17. Re: frequency adjusting only

    maxime louvel wrote:

    > Sorry it's actually difficult for me to precise this topic for
    > confidentiality reason of course and also because I'm an intern and thus


    You employer needs to engage a specialist consultant under
    non-disclosure agreement.

    > there for a short period. Hence I don't know exactly why myself. This is
    > just one of the requirement of my project.


    It is not possible for you to do a competent job unless you understand
    the context. Very often people try and delegate a sub-problem when the
    best overall solution doesn't have that sub-problem. Unless the person
    trying to solve the sub-problem, knows the wider context, they can never
    come up with a solution that says the sub-problem doesn't need solving,
    nor can they find a valid compromise solution, as they don't know what
    parts of the problem can be compromised.

    The only situations where one would normally not have that context is
    where some sort of military-like need to know security applies, in which
    case it would be unlikely that you would be asking on a public forum, or
    when the project is an academic homework exercise, but this thread has
    gone on rather long for that.

  18. Re: question on ntp burst

    Rajaram wrote:
    > 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


    Burst mode is intended for systems that contact a time server, typically
    by dial-up telephone, at intervals of several hours. It helps to
    minimize the long distance charges. It will always send eight packets
    at each poll interval.

  19. Re: frequency adjusting only

    >Sorry it's actually difficult for me to precise this topic for
    >confidentiality reason of course and also because I'm an intern and thus
    >there for a short period. Hence I don't know exactly why myself. This is
    >just one of the requirement of my project.


    Keeping a handful of machines synchronized to within 10 microseconds
    might be possible. It won't be easy. It's unlikely to be the cheapest
    overall solution to some problem.

    I suggest you tell your boss that he has given you a hard to impossible
    problem. You are not likely to get 10 uS by just poking a few magic
    parameters into your ntp.conf. Your target is not a reasonable intern
    project.

    [That's just my opinion. I could be way off.]

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


  20. Re: frequency adjusting only

    Hal Murray wrote:
    >> Sorry it's actually difficult for me to precise this topic for
    >> confidentiality reason of course and also because I'm an intern and thus
    >> there for a short period. Hence I don't know exactly why myself. This is
    >> just one of the requirement of my project.

    >
    > Keeping a handful of machines synchronized to within 10 microseconds
    > might be possible. It won't be easy. It's unlikely to be the cheapest
    > overall solution to some problem.
    >
    > I suggest you tell your boss that he has given you a hard to impossible
    > problem. You are not likely to get 10 uS by just poking a few magic
    > parameters into your ntp.conf. Your target is not a reasonable intern
    > project.
    >
    > [That's just my opinion. I could be way off.]
    >


    The OP might also ask his supervisor just what problem he is trying to
    solve! 10 microseconds might be achievable but doing so would be
    sufficiently expensive that the costs should be clearly understood by
    all those involved.

    Ten MILLISECONDS is easily achievable and is far better than most sites
    need.

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