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.
Re: Looking for clean C source code of algorithms in RFC 1305
Micky wrote:[color=blue]
> 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.
>[/color]
I hope your asbestos suit is not at the cleaners!!
Re: Looking for clean C source code of algorithms in RFC 1305
Micky wrote:[color=blue]
> The C source code for clock selection algorithms included in RFC 1305[/color]
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.
[color=blue]
> 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.[/color]
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.
[color=blue]
>
> 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[/color]
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.
[color=blue]
> response with the best time offset) to be used for clock/time update.[/color]
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.
[color=blue]
> In other words, source code written by professional software
> engineers.[/color]
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.
Re: Looking for clean C source code of algorithms in RFC 1305
On Sep 30, 4:38*pm, David Woolley
<da...@ex.djwhome.demon.co.uk.invalid> wrote:[color=blue]
> Micky wrote:[color=green]
> > The C source code for clock selection algorithms included in RFC 1305[/color]
>
> 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.
>[/color]
It has both.
[color=blue][color=green]
> > 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.[/color]
>
> 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.
>
>[/color]
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.
Re: Looking for clean C source code of algorithms in RFC 1305
Micky wrote:[color=blue]
> On Sep 30, 4:38 pm, David Woolley[/color]
[color=blue][color=green]
>> I thought there was only pseudo code in RFC 1305, not C code.
>>[/color]
>
> It has both.[/color]
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.