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

Hal Murray 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 
page faults.

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
     61  0.395   d0 . 3 4 651622 61856
      1   1.16   d0 . 3 4 226293  3083
      2   1.59   d0 . 3 4 164302 30105
      2   1.89   d0 . 3 4 138149 45984
     21   2.39   d0 . 3 4 109543 60992

These are my opinions.  I hate spam.

More information about the devel mailing list