uk pool problem - NTP

This is a discussion on uk pool problem - NTP ; On 2006-08-31, Ronan Flood wrote: > Perhaps rather than being retired, ntpdate should have the > time-setting code removed and be renamed something like ntpping, > with -qu always set. I for one find it a useful diagnostic tool in ...

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

Thread: uk pool problem

  1. Re: uk pool problem

    On 2006-08-31, Ronan Flood wrote:

    > Perhaps rather than being retired, ntpdate should have the
    > time-setting code removed and be renamed something like ntpping,
    > with -qu always set. I for one find it a useful diagnostic tool in
    > query-only and debug modes.


    The source code is freely available. Any volunteers?

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

  2. Re: uk pool problem

    Ronan Flood wrote:

    > Harlan Stenn wrote:
    >
    >
    >>-d is covered, and while there may not be an exact duplicate there is a -d

    >
    > Perhaps rather than being retired, ntpdate should have the time-setting
    > code removed and be renamed something like ntpping, with -qu always set.
    > I for one find it a useful diagnostic tool in query-only and debug modes.
    >


    Why bother? The -d option tells it not to set the clock and that's much
    easier than removing the clock setting code and distributing the updated
    version.

    Let's face it! Deprecated or not, ntpdate is here to stay and some
    people WILL continue to misuse it. If people misuse it, their clocks
    may not be as accurate or reliable as they might otherwise be. Ntpd has
    the means to defend against such clocks.

    Just think of it as evolution in action!

  3. Re: uk pool problem

    Ntpdate has known bugs and nobody wants to fix it.

    The combinations of the improvements to ntpd and the addition of sntp should
    cover it. If -u is really needed, then it should be needed for both ntpd
    and sntpd, and the case for this as not, to my knowledge, been made.

    If the debugging information provided by ntpdate's -d is significantly
    different from the debug information provided by ntpd or sntp, somebody
    should speak up, with specific recommendations.

    And regarding sntp, the most recent maintainer has disappeared - we need
    somebody to step up and take over the care and feeding of sntp.

    H

  4. Re: uk pool problem

    >>> In article , Ronan Flood writes:

    Ronan> http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html

    Ronan> "ntpdate sets the local date and time by polling the Network Time
    Ronan> Protocol (NTP) server(s) given as the server arguments to determine
    Ronan> the correct time. It must be run as root on the local host. A number
    Ronan> of samples are obtained from each of the servers specified and a
    Ronan> subset of the NTP clock filter and selection algorithms are applied
    Ronan> to select the best of these. Note that the accuracy and reliability
    Ronan> of ntpdate depends on the number of servers, the number of polls each
    Ronan> time it is run and the interval between runs."

    And ntpdate never did this well, and nobody wanted to maintain it, and Dave
    fixed ntpd so it did not need ntpdate anymore.

    On a system with a properly configured ntp.conf file and a decent value in
    the drift file, ntpd will hit the ground and be ready to go in about 11
    seconds. To my knowledge, this was simply not possible before iburst.

    ntpdate has problems, and if you simply want to set the time in a hurry and
    not worry about how stable timekeeping is, sntp will do the same job and it
    does not have ntpdate's problems.

    If somebody wants to keep using ntpdate (which could turn in to a shell
    script as far as I'm concerned) somebody will have to step up and volunteer
    to do the work.

    Note that there are currently also open bugs on ntptrace that have not been
    fixed, either.

    These problems can also be fixed with money.

    H

  5. Re: uk pool problem

    Danny Mayer wrote:
    > I don't understand how they [the pool operators?] determine who can
    > register an NTP pool server but if they accept addresses from anyone
    > they have a major problem if it is true that it shouldn't have been
    > added to the pool.


    Anyone with a static IP and some bandwidth to spare can offer a server
    to the Pool. However, the Pool actually only offers servers that it
    has validated as giving "reasonably accurate" time (I believe that this
    means accuracy to within about +/- 500ms, but offhand I can't remember).

    The Pool offers fair-use ntp service to anyone who wants it. I know there
    have been discussions about ntpd vs ntpdate, but the biggest problem
    is users who have software that polls the pool servers at least once
    every second.


    > Additionally there is evidence that the server sometimes gives a totally
    > incorrect answer but it's not clear to anyone why.


    I suspect that the server may differentiate ntpdate queries and ntpd
    queries, and gives duff information to ntpdate users or whose who query
    "too frequently".

    Does the OP's client respond to KoD packets? Does the server try issuing
    them before sending duff date/time values?


    > There's no information on the web site for the pool to indicate who
    > owns or is the contact for this server.


    Fair point. I'll raise this as a discussion issue on the Pool mailing list
    (see https://fortytwo.ch/mailman/cgi-bin/...fo/timekeepers)

    Chris

  6. Re: uk pool problem

    Eugen COCA wrote:
    > 1. Use ntpd not ntpdate;


    > 2. Use a large number of servers (more than 9);


    That seems rather excessive. If you're using the Pool at all, then three
    or so should be enough. (If you want better time keeping, use specific
    servers rather than the Pool.)

    > 3. Use pool servers and manually entered servers addresses;


    As I understand it, the point of the Pool was to offer an easy way for
    people to configure their clients, without needing to find addresses of
    specific servers. If you've got explicit servers configured, then you're
    unlikely to need the Pool as well.

    Chris

  7. Re: uk pool problem

    In article Martin Burnicki
    writes:
    >Ronan Flood wrote:
    >> Harlan Stenn wrote:
    >>
    >>> -d is covered, and while there may not be an exact duplicate there is a
    >>> -d flag for ntpd and the sntp command has a way to query the time without
    >>> setting it. If there is a particular thing you need that is not covered
    >>> open up an enhancement request.
    >>>
    >>> I have not looked at -u.

    >>
    >> Perhaps rather than being retired, ntpdate should have the time-setting
    >> code removed and be renamed something like ntpping, with -qu always set.
    >> I for one find it a useful diagnostic tool in query-only and debug modes.

    >
    >Full ack. I very often use it for debugging and testing. The only thing I
    >find deprecated is to use the way it has been used before the -g option had
    >been introduced, namely to set the initial system time.
    >
    >I wouldn't even remove the capabiltiy to send requests via either a
    >priviledged or an unpriviledged port. This is very useful to check whether
    >there's some kind of firewall between the test system and the NTP server
    >which only allows for unpreviledged ports and blocks priviledged, or
    >vice-versa.


    This would actually have to be an enhancement - when wanting to check if
    the discussed server possibly used the source port to determine whether
    to give a bogus answer, I found somewhat to my surprise that it's not
    possible to have ntpdate use source port 123 without setting the clock.
    A patch to make -u independent of -q and -d is trivial of course, but
    where to send it?:-)

    --Per Hedeland
    per@hedeland.org

  8. Re: uk pool problem


    Per Hedeland wrote:
    > A patch to make -u independent of -q and -d is trivial of course, but
    > where to send it?:-)


    As someone tells us in a quite transparent mode, if you'll atach a
    cheque to the bug it will be almost impossible to think you'll not be
    able to find an Email address to send them (the bug and the cheque).
    Joking, but I know from my experience ... the more you try to improve a
    thing the more you waste your time. As we where told, ntpdate is
    retired and if you really want to set-up your computer time like
    ntpdate do you may look at your watch atfer setting it by looking at
    the result of an ntptrace command. If you want better results, use ntpd
    ....

    Having fun, as at this very moment I've discovered the NTP.pool.org is
    in a very big trouble. It seems that their "reference" server(s)
    is(are) not in their best days (offsets of 600 to 1200 ms or more are
    not quite good). Still watching the behaviour of the system. For those
    interested, all ro.pool.ntp.org servers are tracked in this page:

    https://ecoca.eed.usv.ro/mrtg/time_s...l.ntp.org.html


  9. Re: uk pool problem


    Chris Davies wrote:
    > Eugen COCA wrote:
    > > 1. Use ntpd not ntpdate;

    >
    > > 2. Use a large number of servers (more than 9);

    >
    > That seems rather excessive. If you're using the Pool at all, then three
    > or so should be enough. (If you want better time keeping, use specific
    > servers rather than the Pool.)


    It doesn't matter if a server is or not in the pool. From the point the
    view of NTP more servers, theoreticaly, means more accuracy. I said
    theoreticaly because I had a very bad experience with one of my server.
    I have the GPS and the PPS souces and a number of "reference" servers
    in order to sync to a source if the GPS is not available. Due to
    extreme network condition (the packets where routed on different routes
    when going from and respectivelly when comming to my server), all ntp
    servers where 40 ms of the real time. So, ntpd dropped the GPS source
    as bad and synced with the external servers. The problem was solved by
    using the "noselect" option for all external servers.


    > > 3. Use pool servers and manually entered servers addresses;

    >
    > As I understand it, the point of the Pool was to offer an easy way for
    > people to configure their clients, without needing to find addresses of
    > specific servers. If you've got explicit servers configured, then you're
    > unlikely to need the Pool as well.


    I do not agree with this opinion. I'll explain why: the pool contains
    very many servers. Some of them are "premium" server, others are
    "second-hand" servers and the worst category is "sporadic servers".
    "Premium servers" means that the server is at least GPS synced or,
    better, GPS + PPS (minimum from the GPS or better with OCXO, Rb, CS or
    H). These are dedicated servers with UPSs and very good network
    connection (min. 10Mbps to Internet up/down, not x/ADSL links !). And,
    very important, an administrator to log-in every day or to look to the
    logs ... In this category you may find no more than 20 percent from the
    total. I have 3 servers in this category at my location. "Second-hand"
    servers are usually Stratum 2 servers, synced on Internet with Stratum
    1 servers. Many Stratum 2 servers in the pool are not only time
    servers, they are web, mail, ssh, etc (try to connect to specific port
    and you'll find out I'm right) servers. I' estimated to 60 percent the
    number of these servers. "Sporadic servers" are the servers that are
    not switched-on all the time or are Stratum 3 or more. The pool have a
    good time reference server to compare with the time received from the
    servers in the pool and making a score.

    In conclusion, it is always better to use some "premium" servers in
    your conf file.


  10. Re: uk pool problem

    Open an enhancement request at http://ntp.isc.org/bugs and after the issue
    is created use the "attachment" procedure to submit your patch to the
    report.

    H
    --
    >>> In article , per@hedeland.org (Per Hedeland) writes:


    Per> This would actually have to be an enhancement - when wanting to check
    Per> if the discussed server possibly used the source port to determine
    Per> whether to give a bogus answer, I found somewhat to my surprise that
    Per> it's not possible to have ntpdate use source port 123 without setting
    Per> the clock. A patch to make -u independent of -q and -d is trivial of
    Per> course, but where to send it?:-)


  11. Re: uk pool problem

    >>> In article <1157137669.266818.194790@i3g2000cwc.googlegroups.c om>, "Eugen COCA" writes:

    Eugen> As someone tells us in a quite transparent mode, if you'll atach a
    Eugen> cheque to the bug it will be almost impossible to think you'll not be
    Eugen> able to find an Email address to send them (the bug and the cheque).

    Indeed. Visit http://ntp.isc.org and you will find on the left-hand menu a
    link to "Bugs & Issues" just above "Donations".

    Eugen> Joking, but I know from my experience ... the more you try to improve
    Eugen> a thing the more you waste your time.

    I know it can be Difficult to get a new refclock added to the code. If
    there are other areas in the project where anybody is having difficulty
    trying to get their improvements in, please let me know. And please
    remember I am still a volunteer on this project, too.

    Eugen> As we where told, ntpdate is
    Eugen> retired and if you really want to set-up your computer time like
    Eugen> ntpdate do you may look at your watch atfer setting it by looking at
    Eugen> the result of an ntptrace command. If you want better results, use
    Eugen> ntpd ...

    or sntp.

    H

  12. Re: uk pool problem

    Per Hedeland wrote:
    > In article Martin Burnicki
    > writes:
    >
    >>Ronan Flood wrote:
    >>
    >>>Harlan Stenn wrote:
    >>>
    >>>
    >>>>-d is covered, and while there may not be an exact duplicate there is a
    >>>>-d flag for ntpd and the sntp command has a way to query the time without
    >>>>setting it. If there is a particular thing you need that is not covered
    >>>>open up an enhancement request.
    >>>>
    >>>>I have not looked at -u.
    >>>
    >>>Perhaps rather than being retired, ntpdate should have the time-setting
    >>>code removed and be renamed something like ntpping, with -qu always set.
    >>>I for one find it a useful diagnostic tool in query-only and debug modes.

    >>
    >>Full ack. I very often use it for debugging and testing. The only thing I
    >>find deprecated is to use the way it has been used before the -g option had
    >>been introduced, namely to set the initial system time.
    >>
    >>I wouldn't even remove the capabiltiy to send requests via either a
    >>priviledged or an unpriviledged port. This is very useful to check whether
    >>there's some kind of firewall between the test system and the NTP server
    >>which only allows for unpreviledged ports and blocks priviledged, or
    >>vice-versa.

    >
    >
    > This would actually have to be an enhancement - when wanting to check if
    > the discussed server possibly used the source port to determine whether
    > to give a bogus answer, I found somewhat to my surprise that it's not
    > possible to have ntpdate use source port 123 without setting the clock.
    > A patch to make -u independent of -q and -d is trivial of course, but
    > where to send it?:-)
    >
    > --Per Hedeland
    > per@hedeland.org


    Since no one is maintaining ntpdate I don't believe that there is any
    place to send a patch where it will actually get applied to the
    distributed code. (I may be wrong, it's a sometimes specialty of mine! :-)

    I'd suggest posting it here, if it's small, or posting a link to
    somewhere that people who need it can grab it.

  13. Re: uk pool problem

    On 2006-09-01, Richard B. Gilbert wrote:

    > Per Hedeland wrote:
    >[---=| Quote block shrinked by t-prot: 29 lines snipped |=---]




    >> A patch to make -u independent of -q and -d is trivial of
    >> course, but where to send it?:-)

    >
    > I'd suggest posting it here, if it's small, or posting a link to
    > somewhere that people who need it can grab it.


    You can open an enhancement request at http://bugs.ntp.isc.org and
    attach the patch.

    Just create a "new bug" for ntpdate, which is listed as a component of
    ntp, and set the priority appropriately.

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

  14. Re: uk pool problem


    Harlan Stenn wrote:
    > If
    > there are other areas in the project where anybody is having difficulty
    > trying to get their improvements in, please let me know. And please
    > remember I am still a volunteer on this project, too.


    Harlan,

    I think there where opinions redarding this "bug" on this group, but
    I'll repeat: it will be very useful for the ntpd to try to reload the
    conf file from time to time and try to connect to servers listed there.
    Now, when ntpd starts, it will try to connect to the servers listed, in
    the order of their appearance in the ntp.conf file. If one server fail
    to respond it will be eliminated for further checks. This will be very
    usefull as on some systems (mostly on Windows machines).

    Regards,


  15. Re: uk pool problem

    I *think* this will be handled by the upcoming config file rewrite code.

    That should appear in ntp-dev in a month or so (just after 4.2.4 is out).

    H
    --
    >>> In article <1157168655.826350.117260@m73g2000cwd.googlegroups. com>, "Eugen COCA" writes:


    Eugen> I think there where opinions redarding this "bug" on this group, but
    Eugen> I'll repeat: it will be very useful for the ntpd to try to reload the
    Eugen> conf file from time to time and try to connect to servers listed
    Eugen> there. Now, when ntpd starts, it will try to connect to the servers
    Eugen> listed, in the order of their appearance in the ntp.conf file. If one
    Eugen> server fail to respond it will be eliminated for further checks. This
    Eugen> will be very usefull as on some systems (mostly on Windows machines).

  16. Re: uk pool problem

    I'm really not sure about this.

    If somebody expressed an interest in fixing this problem, I'd be inclined to
    ask them if they were interested in fixing the other problems with ntpdate.

    If they said "yes" then we'd have a maintainer for ntpdate and this would
    not be an issue.

    H
    --
    >>> In article , "Richard B. Gilbert" writes:


    Richard> Since no one is maintaining ntpdate I don't believe that there is
    Richard> any place to send a patch where it will actually get applied to the
    Richard> distributed code. (I may be wrong, it's a sometimes specialty of
    Richard> mine! :-)

  17. Re: uk pool problem

    In article Harlan Stenn
    writes:
    >I'm really not sure about this.
    >
    >If somebody expressed an interest in fixing this problem, I'd be inclined to
    >ask them if they were interested in fixing the other problems with ntpdate.
    >
    >If they said "yes" then we'd have a maintainer for ntpdate and this would
    >not be an issue.


    So is it deprecated or not? If it is, it would seem very strange to
    consider enhancements (which was the point of my tongue-in-cheek
    question earlier). Or are you saying that the *only* reason it is
    deprecated is that there is no maintainer? That would certainly be
    news...

    FWIW, I can see several objectively valid reasons to deprecate ntpdate,
    and even a subjective one like "we don't like it" would have to be
    considered valid - obviously no one can *demand* that you support some
    particular piece of software (at least not without handing over money).

    The problem that I see, and that leads to this tiresome re-hashing, is
    that the arguments brought forward by those that want to have ntpdate
    deprecated are almost uniformly bogus - like the absurd suggestion in
    this thread that even though ntpdate allows you to specify multiple
    servers, it wouldn't "do anything special" if one of them was 6 years
    behind the others. This of course leaves you wondering if the desire to
    deprecate ntpdate is actually based on nothing but ignorance.

    Now you are saying that ntpdate has lots of problems - I can't really
    deny that, but that's at least in part because I don't know what you're
    refering to. If it's just those listed on bugzilla, I'll have to say
    that I couldn't find anything significant in need of a fix there (I can
    elaborate if wanted). But maybe you're thinking of other problems?

    --Per Hedeland
    per@hedeland.org

  18. Re: uk pool problem

    Per Hedeland wrote:
    > In article Martin Burnicki
    > writes:
    >> Ronan Flood wrote:
    >>> Harlan Stenn wrote:
    >>>
    >>>> -d is covered, and while there may not be an exact duplicate there is a
    >>>> -d flag for ntpd and the sntp command has a way to query the time without
    >>>> setting it. If there is a particular thing you need that is not covered
    >>>> open up an enhancement request.
    >>>>
    >>>> I have not looked at -u.
    >>> Perhaps rather than being retired, ntpdate should have the time-setting
    >>> code removed and be renamed something like ntpping, with -qu always set.
    >>> I for one find it a useful diagnostic tool in query-only and debug modes.

    >> Full ack. I very often use it for debugging and testing. The only thing I
    >> find deprecated is to use the way it has been used before the -g option had
    >> been introduced, namely to set the initial system time.
    >>
    >> I wouldn't even remove the capabiltiy to send requests via either a
    >> priviledged or an unpriviledged port. This is very useful to check whether
    >> there's some kind of firewall between the test system and the NTP server
    >> which only allows for unpreviledged ports and blocks priviledged, or
    >> vice-versa.

    >
    > This would actually have to be an enhancement - when wanting to check if
    > the discussed server possibly used the source port to determine whether
    > to give a bogus answer, I found somewhat to my surprise that it's not
    > possible to have ntpdate use source port 123 without setting the clock.
    > A patch to make -u independent of -q and -d is trivial of course, but
    > where to send it?:-)
    >
    > --Per Hedeland
    > per@hedeland.org
    >


    As I recall, the protocol requires that the source port be 123 but the
    ntpd reference server implementation does not enforce that. I don't
    recall where I read it. That said it seems useful to differentiate
    between an ntpd server requesting time and a client requesting time via
    ntpdate. Nevertheless a server shouldn't return time at all unless it's
    a KOD packet if it doesn't want to accept packets at all. This one seems
    to return a specific packet value if queried via ntpdate. I seems to me
    that this is more a WG discussion and probably should be discussed there.

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


  19. Re: uk pool problem

    Richard B. Gilbert wrote:
    > Since no one is maintaining ntpdate I don't believe that there is any
    > place to send a patch where it will actually get applied to the
    > distributed code. (I may be wrong, it's a sometimes specialty of mine! :-)
    >
    > I'd suggest posting it here, if it's small, or posting a link to
    > somewhere that people who need it can grab it.
    >


    That's not quite true. If someone submits a bug report and a proposed
    fix and it does fix the reported problem then we put it in.

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


  20. Re: uk pool problem

    Eugen COCA wrote:
    > Harlan,
    >
    > I think there where opinions redarding this "bug" on this group, but
    > I'll repeat: it will be very useful for the ntpd to try to reload the
    > conf file from time to time and try to connect to servers listed there.
    > Now, when ntpd starts, it will try to connect to the servers listed, in
    > the order of their appearance in the ntp.conf file. If one server fail
    > to respond it will be eliminated for further checks. This will be very
    > usefull as on some systems (mostly on Windows machines).
    >
    > Regards,
    >


    Eugen, please enter an enhancement request for this. It would be a
    useful addition, potentially. It may not be simple to implement but
    would be a similar effort to what is being done for local IP addresses
    and the way the change due to DHCP changing it from time to time.

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


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