CPU load on FreeBSD. Classic NTP 5-6% vs NTPsec 10-17%

[Mike Yurlov]

> My best guess is that we are now using crypto
> quality random numbers where we don't need them.  That and nobody has reported
> CPU problems yet.  You are probably the first one to have enough traffic to
> notice.  Thanks for the data point.

Hmmm... When I increase mru size, cpu extremely increased too. Changes 
of query rate/pps does not affect so much. I will do some test with mru 
size. Looks like the problem is here. But ntpsec ntp_list.h is totally 
like classic. I'm at a loss.  Perhaps BSD have some issues in CLANG 
compiler flags or Python, or need another malloc/memory operation calls, 
I don't know. Therefore I am here.

I'm not first one with 3-4kpps traffic (I'm guess many ntp pool hosts 
have it). But I use 1) BSD, not Linux  2) without gpsd and shm 
interlayers. Only native "nmea" and only GNGGA/GPGGA messages (all other 
are switched off).
Building on latest BSD have "'AnsiTerm' object has no attribute 
'buffer'". Google gives me workaround from mailing list:
sh (go to "sh" shell, generally I use tcsh)
NOSYNC=1 ./waff configure --refclock=all (or local,nmea,pps)
NOSYNC=1 ./waff build
NOSYNC=1 ./waff install


> Anything interesting in ntpq monstats?

I test some solutions here. Best filtering tool is the firewall, but 
unfortunately BSD firewalls does not have a filter function by 
packetrate or traffic volume like iptables.  Now i use traffic collector 
to count traffic + simple cron script and block overly active hosts and 
crap for some hours. Therefore, flooders does not load NTP daemon too 
much and mrulist does not grow excessively. Nevertheless sysstats show 
~3% "bad length or format" and ~3% rate limited hosts.

Among other things server recieve ~0.5-1% of traffic from "gray" subnets 
(192.168/16, 10.0.0.0/8 and so on) coming from "big Internet" from other 
ISP. My recommendation for public NTP server owners: read RFC6890 and 
block unneeded (for you) ip ranges with firewall. As usual your ISP 
don't have correct reverse path for this ip and you should not send them 
back, creating a load on the network.

Let's get back to CPU loading :)

--
Mike