Back to active participation

[Hal Murray]

[Sorry for the delay.]

Welcome back.  It will be good to have somebody thinking about the big 
picture.

We're a bit low on manpower.  Is there a critical mass needed for a 
project like this?

I made noises about a release a month or two ago, but then I got 
distracted.  I hope to get back to that soon.  There are several bugs that 
need fixing.

I haven't been paying a lot of attention to NTv5.  That would be a good 
project after a release.

--------

Our code currently drops packets that don't pass crypto checks.  We should 
fix that to return a non authenticated answer.  The idea is to aid in 
debugging.  The client can tell that the packet got through so the routing 
works and the crypto is probably broken.  This is reasonably high on my 
to-do list.

We should switch setting up the log file from the config file to the 
command line.  That will put error messages from parsing the config file 
into the log file where I look.

We should test/review buildprep before each release.  Package names change 
occasionally and/or we may want to switch to a newer version on a system 
that supports old and new.  Is that on the list?

--------

It would be nice if we could do more testing.  I don't have a great plan.

It would be neat if we could automate some tests of the actual 
to-be-shipped ntpd.  There is already a -q option that exits after setting 
the time so we should be able to do a lot of this without changing any 
code.

One idea is to actually run ntpd in (some of) the CI builds.  We could, 
for example, verify that the client side of NTS actually works.

We could also make a long script that tested all sorts of combinations on 
the just-built system.  For example, we could see if all the command line 
options and all the config file parser options at least get past the 
parser.

It would be nice if we had a tested-matrix for each of our releases 
showing what we have tested for various distros/versions.  This could 
include refclocks.

There is shutdown code that tries to free all the memory we have 
allocated.  It would be interesting to run valgrind and see what it misses.

Mumble.  Lots of opportunities.

--------

Support for 32 bit systems is getting hard to find.  Raspbian still 
supports Pi 1 and Pi 2.  Alpine Linux has support for X86 and old Pis.  I 
haven't tried it.

Are there any modern big endian systems in use?.  Anybody know of a low 
cost big endian hardware and a distro that supports it?  It would be nice 
to test on one, just to make sure our code does the right swapping.  I 
used to have a Mac Mini (I think) but it died.  That was a long time ago.

--------

> On crypto, expect informed opinions and the occasional patch around TLS
> and our crypto dependencies.

There are 2 NTS areas that need some thought and work.  One is getting 
started if your system doesn't have a battery backed clock.  The other is 
the AEAD implementations.  I'll put something in separate messages.

The IETF NTP-WG is working a pool that supports NTS.  For a pool like the 
current one with zillions of volunteers, that hides who you are trusting.  
Pool technology makes sense if you have one organization running the whole 
show -- then you know who you are trusting.  That works for things like:
  pool time.cloudflare.com nts

--------

I would like to threadify things.  No firm proposal.  Part of the idea is 
to split the server off to a separate program so I can make a 
multi-threaded server which will handle lots of traffic.  I'll say more if 
anybody is interested.

There is an option in most kernels to do the PPS processing in the kernel. 
 It's not enabled in Linux kernels because it conflicts with power saving. 
 I build kernels with it enabled.  It works much better.  (I should make a 
web page with some graphs.)  I'd like to implement that code in user mode. 
 I think the overhead of a few system calls won't break things.

Are you in touch with router/IoT vendors and/or OpenWRT?  There is a lot 
of really old NTP code running out there.  It would be nice if somebody 
wrote a clean NTP client intended for low end systems.  (And if the 
hardware has a real serial port or USB and a GPIO pin we could get good 
timing which which would allow measuring transit times.  That might be 
interesting to some geeky network hackers.)

I think I fixed the MSSNTP option a while ago.  As far as I know, nobody 
has used it so I don't know if it actually works in a real Windows world.

--------

Eric pushed a handful of patches a while ago.
  commit 5ac1f369637288033b018be3831055e9015c1cf6
  Author: Eric S. Raymond <esr at thyrsus.com>
  Date:   Mon Apr 27 09:47:18 2026 -0400  (and several others)
  
    Bug found by ChatGPT 5.5, which considered it severity 'Medium'.

One of them changed the order that servers get processed at startup.  That 
seems wrong, but I haven't investigated yet.

A couple of others raised an interesting area.  What should we do about 
errors that shouldn't happen, but if they do don't actually kill the whole 
system.  For example, not being able to get a thread for a DNS lookup.  I 
think we have 3 choices:
  1: crash
  2: try again later, probabaly adding a lot of clutter in the log file
  3: bail, leaving the DNS thread dead but the rest of the system working
I implemented 3 but didn't include a comment as to what/why.
Eric changed it to 2

I've never seen this error happen.  Should we really invest time/effort in 
recovery code that will never get used?  Or tested?  Should we add code to 
do an exponential backoff so the log file doesn't get trashed?



-- 
These are my opinions.  I hate spam.