Hi All!
I recently started the public server for ntppool (Yo, Ask) on FreeBSD.
Yesterday I was migrate from Classic NTPd to NTPSec (oh, it was
painful!). I'm copy ntp.conf to ntpsec.conf and only convert "magic"
127.127.20 x to refclock. 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?
System is FreeBSD 12.1-STABLE r353872, kernel compiled with options
PPS_SYNC. Hardware is not new (but overhead for single ntpd) - 1RU MSI
server with 6Gb memory and Intel(R) Core(TM)2 Quad CPU Q9400 @2.66GHz.
Sources:
1) uBlox 8 GPS+GLONASS on RS232 + PPS (primary and prefer)
2) Garmin 18x LVC on RS232 (backup and "noselect" because it have big
jitter and does not have GLONASS)
3) some ntp Stratum1 servers
Classic NTPd is from BSD distribution/sources, version 4.2.8p13. NTPSec
is 1.1.8 from .tar.gz.
I'm copy ntp.conf to ntpsec.conf and only convert "magic" 127.127.20 x to
refclock nmea unit 0 prefer mode 0x10000 minpoll 2 maxpoll 4 time2
0.1782 refid GPS path /dev/gps0 baud 9600 flag1 1 flag2 0 flag3 1
refclock nmea unit 1 noselect mode 0x10000 minpoll 4 maxpoll 4 time2
0.542 refid GPS path /dev/gps1 baud 4800 flag1 0 flag2 0 flag3 1
and run daemon as ntp -c ntpsec.conf
I read some topics/issues and suggest "server have many bad/flood
queries (i'ts true, I'm inspecting traffic dump), so let's increase mru
size?". Ok, I have 6Gb memory and powerfull CPU (for one ntpd task),
therefore I' configure (values from some ntpsec issue topic):
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).
I comment mru settings and now have 12-17% again. It's 2x times more
then Classic. NTPSec positioned as an improved alternative to the
classic NTPd with code cleaning and optimization. Why so much CPU?
--
Mike
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
