CPU load on FreeBSD. Classic NTP 5-6% vs NTPsec 10-17%
hmurray at megapathdsl.net
Fri Dec 13 13:45:53 UTC 2019
> When I looking to "top" I see NTPsec eat 10-17% CPU. But Classic NTPd eat
> only 4-6% on same average 3-4kpps/queries per second. Why?
I don't have a clean answer. 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.
I'm actually working on that area. What should have been a simple fix breaks
things in a way that I don't understand (yet) so I can't give you a fix to
try. I'll get back to you when I have something ready.
> mru initmem 100000 maxmem 250000 maxage 90000 minage 3600 incmem 1000
> strange, but when I restart daemon, I does not see ~100M memory in ps/top
> output, only ~20M as usual and it increased slowly. After that I went to bed
> and ~7 hours later in the morning I have ~100Mb memory and 68-70% ntpd CPU
> in "top". WOW! (I met similar behavior in very old traffic collecting
> daemons that use linear ip search in arrays without hashes).
There is a hash table in there. I'd expect the per-packet processing to be
slightly slower after the table gets filled up, but it should be only a few
Anything interesting in ntpq monstats?
I'm slightly surprised that you only got to 100M of memory with 7 hours of
3-4kpps/queries per second. I'd expect more.
You can get info on bad guys with
ntpq -nc "mru mincount=100000 sort=avgint"
Adjust the 100000 to fit.
I see things like this on a pool server:
lstint avgint rstr r m v count rport remote address
33146 0.161 d0 . 3 4 538033 39610 188.8.131.52
61 0.395 d0 . 3 4 651622 61856 184.108.40.206
1 1.16 d0 . 3 4 226293 3083 220.127.116.11
2 1.59 d0 . 3 4 164302 30105 18.104.22.168
2 1.89 d0 . 3 4 138149 45984 22.214.171.124
21 2.39 d0 . 3 4 109543 60992 126.96.36.199
These are my opinions. I hate spam.
More information about the devel