I recently discovered that the “spare” Raspberry PI CM5 Development box for a project could operate very well as a headless server hosting the NTP, BIND9, and Apache servers that were hosted elsewhere on the network in fairly antique FreeBSD instances. The old NTPD instance became rather dodgy above the “3 Mbit” setting.
The new NTPsec instance in the R Pi settled down almost immediately, and when turned loose with the 3 Mbit setting largely failed to register in the local CPU usage monitor. Looking at the MRU list, the number of unique clients per minute hovered around 170. So, why not do something bold: 12 Mbit.
NTPsec began to slowly move up the process list on htop, but rarely registered any CPU usage. The monitors were happy: solid ‘20’ worldwide. About 2000 ucpm.
On then, to 50 Mbit. About 6000 ucpm. Occasional indications of 0.7% CPU usage. Monitors are happy.
100 Mbit: 9,000 to 10,700 ucpm. Occasional “ding” alert from the network monitor, occasional monitor failures. CPU usage still close to undetectable.
250 Mbit: 10,000 to 10,900 ucpm. Frequent “ding” alerts. Some of the briefly unreachable hosts included the border router (I have Spectrum business service – it’s their box). A growing number of monitor failures. The dings stopped when the traffic went below about 450 packets per second.
Back to 50 Mbit. Clearly the limitation is imposed not by the hardware (4-cores at 16 MHz) but by the border router. ~10,700 unique client IPs per minute is roughly the top.
The “dings” come from WS_WATCH, a piece of very durable software from the Windows 95 era, obtained from TUCOWS back when it actually was The Ultimate Collection of Windows Shareware, from Master Sergeant John Junod, who was then at my old duty station, Fort Gordon, GA.