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
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Reply via email to