First, all functionality included, NTPD is presently 363.000 lines of .c and .h files.
Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.
There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.
My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.
I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.
Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:
#define DEFPROPDELAY 0x00624dd3 /* 0.0015 seconds, 1.5 ms */
But doing this takes some code:
critter phk> ./ntimed-client -p pll_std_capture_time
Parameter:
pll_std_capture_time
Minimum:
2.000e+01
Maximum:
1.000e+06
Default:
3.000e+02
Description:
Capture time before stiffning PLL.
After this many seconds, the PLL will start to stiffen the P
and I terms to gain noise immunity. Decreasing risks that
initial frequency capture is not finished, which will increase
the offset-excursion. Increasing just delays this stiffning.
Failure: Stopping after parameter query.
I don't have a target size for the program, but 5-10.000 lines for a robust, reliable, secure and usable time sync client sounds reasonable to me.
... and that will still be less than 3% of the current NTPD.
I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.
I would guess that PHK, being PHK, is just being thorough rather than defensive. After all, if you can avoid a lot of back and forth, you're saving everybody time. Of all people here, he's definitely one of the ones worth giving the benefit of the doubt.
Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.
There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.
My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.
I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.
Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:
But doing this takes some code: I don't have a target size for the program, but 5-10.000 lines for a robust, reliable, secure and usable time sync client sounds reasonable to me.... and that will still be less than 3% of the current NTPD.