Looking for clean C source code of algorithms in RFC 1305 - NTP

This is a discussion on Looking for clean C source code of algorithms in RFC 1305 - NTP ; The C source code for clock selection algorithms included in RFC 1305 is not very clean. The inputs are not well defined, global variables with plenty of side effects, etc. You really have to dig through the whole document to ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Looking for clean C source code of algorithms in RFC 1305

  1. Looking for clean C source code of algorithms in RFC 1305

    The C source code for clock selection algorithms included in RFC 1305
    is not very clean. The inputs are not well defined, global variables
    with plenty of side effects, etc. You really have to dig through the
    whole document to make sense out of it and I do not have the time for
    it.

    I am looking for clean source code that defines clearly entry proc,
    clearly defines input to be provided on the basis of responses
    received from multiple NTP servers, and clearly defines output (e.g. a
    response with the best time offset) to be used for clock/time update.
    In other words, source code written by professional software
    engineers.







  2. Re: Looking for clean C source code of algorithms in RFC 1305

    Micky wrote:
    > The C source code for clock selection algorithms included in RFC 1305
    > is not very clean. The inputs are not well defined, global variables
    > with plenty of side effects, etc. You really have to dig through the
    > whole document to make sense out of it and I do not have the time for
    > it.
    >
    > I am looking for clean source code that defines clearly entry proc,
    > clearly defines input to be provided on the basis of responses
    > received from multiple NTP servers, and clearly defines output (e.g. a
    > response with the best time offset) to be used for clock/time update.
    > In other words, source code written by professional software
    > engineers.
    >


    I hope your asbestos suit is not at the cleaners!!


  3. Re: Looking for clean C source code of algorithms in RFC 1305

    Micky wrote:
    > The C source code for clock selection algorithms included in RFC 1305


    RFC 1305 should be considered obsolete, even though it's replacement is
    still in draft. The replacement is unlikely to help you any more,
    except that it does match the implementation of NTP that has been
    current for several years now.

    I thought there was only pseudo code in RFC 1305, not C code.

    > is not very clean. The inputs are not well defined, global variables
    > with plenty of side effects, etc. You really have to dig through the
    > whole document to make sense out of it and I do not have the time for
    > it.


    My gut feeling is that RFC 1305 is unnecessarily difficult to read,
    partly because it tries to be written for mathematicians, not for
    software developers. However, I doubt that anything easier to read
    exists. If it does, I imagince it is covered by commercial confidentiality.

    >
    > I am looking for clean source code that defines clearly entry proc,
    > clearly defines input to be provided on the basis of responses
    > received from multiple NTP servers, and clearly defines output (e.g. a


    Input is only ever received from one server at a time. That input is
    processed in relation to stored information about earlier responses from
    that server and responses from other servers.

    > response with the best time offset) to be used for clock/time update.


    Note that the offset is as input to the clock discipline filter.
    Although that is given in a non-normative appendix, it is effectively
    part of the normative specification, and may well have been promoted to
    formal normative status in NTP V4. I'm saying this, because it is a
    common misconception that ntpd steps the clock by the offset when ever
    it computes one.

    > In other words, source code written by professional software
    > engineers.


    My experience in the software industry is that that is a very rare
    commodity. In fact the best code is often written by unpaid volunteers,
    because they tend to most knowledgeable, not constrained by coding
    standards, and have not been promoted to management after a couple of
    years of coding.

    If the reference implementation doesn't satisfy you, I suspect that any
    such code only exists behind closed doors. But as the good
    implementations are generally based on the reference implementation, I
    doubt that any actually exist.

    The, obsolete, NTP V3 reference implementation contains an unambiguous,
    real C, definition of the RFC 1305 algorithms, but I think you may find
    it less easy to understand than the RFC.

    If you need to implement NTP, you should adapt the reference
    implementation, preferably the current one, not the one that matches RFC
    1305; the licensing is similar to BSD.

  4. Re: Looking for clean C source code of algorithms in RFC 1305

    On Sep 30, 4:38*pm, David Woolley
    wrote:
    > Micky wrote:
    > > The C source code for clock selection algorithms included in RFC 1305

    >
    > RFC 1305 should be considered obsolete, even though it's replacement is
    > still in draft. *The replacement is unlikely to help you any more,
    > except that it does match the implementation of NTP that has been
    > current for several years now.
    >
    > I thought there was only pseudo code in RFC 1305, not C code.
    >


    It has both.

    > > is not very clean. The inputs are not well defined, global variables
    > > with plenty of side effects, etc. You really have to dig through the
    > > whole document to make sense out of it and I do not have the time for
    > > it.

    >
    > My gut feeling is that RFC 1305 is unnecessarily difficult to read,
    > partly because it tries to be written for mathematicians, not for
    > software developers. *However, I doubt that anything easier to read
    > exists. *If it does, I imagince it is covered by commercial confidentiality.
    >
    >


    The issue is not whether it is easy or difficult to read. The issue
    is
    that you are forced to read it and you should not have to.
    The algorithm should be self-contained with well defined input
    and well defined output. You should not have to spend your time
    to figure out how a bunch of global C variables are related to
    the data received in each response.


  5. Re: Looking for clean C source code of algorithms in RFC 1305

    Micky wrote:
    > On Sep 30, 4:38 pm, David Woolley


    >> I thought there was only pseudo code in RFC 1305, not C code.
    >>

    >
    > It has both.


    As far as I can tell, the C is in a non-normative appendix, and is
    probably just an extract of an early version of the V3 reference
    implementation, which has been thrown in to help clarify the formal part
    of the specification. If you want the formal definition of the
    algorithms, you need to use the pseudo-code. If you want a self
    contained C code implementation, you need to look at the reference
    implementation.

    I must admit I had never noticed the C before, as it a long way from the
    important parts of the document.

+ Reply to Thread