CPU load on FreeBSD. Classic NTP 5-6% vs NTPsec 10-17%
ntp at kaluga.net
Fri Dec 13 16:10:37 UTC 2019
> 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 :)
More information about the devel