Hello – I added some related notes in another thread: Monitoring and packet loss in transit - #3
All the software is on Github and patches are welcome, even if I don’t always apply them super fast (sorry, @lammert! I don’t remember it, but I am guessing you updating the PR made the email thread bump to the top of my inbox so I saw it again. As you might have surmised, I could use help reviewing and screening the various pull requests that come in, in particular for the translations; I don’t know why that’d need to be stuck on me doing it except nobody is helping).
I am personally just, well, one person and the NTP Pool isn’t my only commitment in life, so I only have the time I have. There’s been some years where virtually all the time goes with just one little tweak or fix or distraction after another when I sit down to work on it, so what I often do is “cycle” between areas of concern to get some needed maintenance or a certain improvement put in and then move on to the next.
For example some years ago I spent a lot of time getting the system running in Kubernetes (and getting the k8s cluster up and running and maintained). It was frustrating not spending the time writing software or otherwise improving or adding something new, but the old setup was extremely hard to upgrade in production and the Kubernetes setup completely unlocked that so updates are relatively safe and easy which was great.
Last winter a lot of time went with making the new archiver and getting it in production and getting all the old data properly archived. The code I ended up writing was probably just a few days of work here and there, but I’d previously failed an embarrassing number of times at getting it structured and written in a way that felt like it’d be reliably and low maintenance for the next decade (or whatever) – or the systems I tried using for archiving turned out to not work as well as I’d hoped. The new system is great though and minus a few changes is ready for getting a much higher volume of monitoring data.
In the spring we got told on short notice that the co-location facility we’d been in for a long time was going away. Getting everything moved to another facility and getting the system moved in a way that didn’t cause downtime and then the ongoing “tidying up” afterwards didn’t leave much time for anything else for a while.
As I posted in the other thread linked above, the beta system has some new features that I wanted to build before adding more features on manage.ntppool.org that’d have to be migrated later. I could really use some help testing it though.
This past holiday period I was working on making it easier to run the full Kubernetes setup locally for development (instead of using docker-compose). The motivation for this was that the old system (ksonnet) I’d been using to deploy the application worked great but isn’t maintained anymore and is starting to fall apart on the version of Kubernetes the cluster has been upgraded to.
Anyway – for the server count, I agree that the biggest “cost” on that was the DDOS attacks years ago and servers needing upgrading, etc.
I have maintained the system for about 15 years now and we still have more servers than we ever dreamed about in the first handful of years. We also have more servers than ever with higher capacity and servers in more countries than ever, so … well, I don’t think it’s so bleak. I don’t know if any of the other “free access NTP” systems handle more devices or queries than we do (as @Bas said).