Sorry All! Previous answer was about "Performance tweaks" Hal Murray
question!
About performance: every 1kpps give 1-2% for me regardless mrulist
enabled/disabled . If you want solution for highloaded up to "all cores
100% CPU" servers you can two ways:
1. multithreaded daemon. I think it
cpu affinity? If you have network card with many tx/rx threads (modern
PCI-E card can use MSI-X and 'software irq'), you can bind different
card threads/irqs to cores and ntpd process to other core. On BSD we use
cpuset to spread and bing threads to cores.
On Linux see script set_irq_affinity.
Thanks.
> and without 'limited' on ~5kpps I have 8-10% CPU regardless minitoring
> enabled/disabled. About 1% on 1000pps.
Is that within reason or worth investigating? 1% times 5 should be 5% rather
than 8-10% but there may not be enough significant digits in any of the
numbers.
> For those
and without 'limited' on ~5kpps I have 8-10% CPU regardless minitoring
enabled/disabled. About 1% on 1000pps.
(Hardware is old MS-9258 server, CPU Quad CPU Q940, FreeBSD 12.1)
As I see many limited queries really sourced from NAT, and we cannot
determine whether they are correct or not. So for
Hi, Hal!
I build ntpd from latest sources tonight. CPU load drops from 18-20%
average to 5-6% on my ~3-4k pps. Looks perfect!
If you get race with "init before config read", you can create build
option for the init size of the mrulist.
Here the stats from nigth to 13:00 (GMT+3):
recieded 173
> there are not only DDoS amplifier. I see many dumb queries with 0.3-2 second
> interval. Looks like sources located behind NAT, does not NAT'ed correctly
> and does not recieve my answers. Or just it have "broken" ntp client. Or
> DDoS reflection attack. It still exists by simple queries wi
there are not only DDoS amplifier. I see many dumb queries with 0.3-2
second interval. Looks like sources located behind NAT, does not NAT'ed
correctly and does not recieve my answers. Or just it have "broken" ntp
client. Or DDoS reflection attack. It still exists by simple queries
with spoofed
]>> That turns off monitoring, aka the MRU list.
> I believe that was a security feature to prevent amplification of ddos-type
> attacks. (for ntp classic) Or doesn't this work this way for ntpsec?
That was fixed in ntp classic long before ntpsec forked.
The old code was for the client to send
On 03-01-2020 06:06, Hal Murray wrote:
>
>>> Do you have a "disable monitor" in your ntp.conf?
>> yes
>
> That turns off monitoring, aka the MRU list.
I believe that was a security feature to prevent amplification of
ddos-type attacks. (for ntp classic)
Or doesn't this work this way for ntpsec?
>> Do you have a "disable monitor" in your ntp.conf?
> yes
That turns off monitoring, aka the MRU list.
Comment out that line and restart ntpd and you should get some data. The
default parameters are OK for home use. If your system is in the pool you
probably want to give it more memory.
On 02-01-2020 20:26, Hal Murray wrote:
> That's not the normal output.
>
> Do you have a "disable monitor" in your ntp.conf?
yes
> What does "ntpq -c monstats" show?
# ntpq -c monstats
enabled:0
addresses: 0
peak addresses: 0
maximum addresses: 11915
re
> I see stuff like this:
[no data]
That's not the normal output.
Do you have a "disable monitor" in your ntp.conf?
What does "ntpq -c monstats" show?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntp
On 02-01-2020 11:03, Hal Murray via devel wrote:
> Is anybody other than me and Mike interested in large MRU lists?
I see stuff like this:
# ntpq -c mru
Ctrl-C will stop MRU retrieval and display partial results.
lstint avgint rstr r m v count rport remote address
==
hmur...@megapathdsl.net said:
> The MRU hash table was limited to 16 bits. I have no idea why. It's
> probably leftover from when even big machines didn't have much memory. I'm
> about to go fix that. Should be simple, but I've said that before
I just pushed a cleanup of that area. CPU u
> The synthetic load with only one client is far away from real production
> load of thousands of requests per second from around the world. As the owner
> of the production server from the ntppool, I am very interested in
> performance.
I think the no-MRU (or early/small MRU) case should be a
The synthetic load with only one client is far away from real production
load of thousands of requests per second from around the world. As the
owner of the production server from the ntppool, I am very interested in
performance.
I suggest using the following realistic test mode: big source ad
I found the missing line of code that was breaking no-FUZZ. I found several
other quirks while browsing the code.
I'm starting to work on performance numbers.
With no-FUZZ:
A Pi 3 can support 18-19K packets/sec. 22-23K with monitoring turned off.
An Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
17 matches
Mail list logo