Re: Fuzz, Numbers

2020-01-13 Thread Mike Yurlov via devel
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

Re: Fuzz, Numbers

2020-01-13 Thread Mike Yurlov via devel
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.

Re: Fuzz, Numbers

2020-01-13 Thread Hal Murray via devel
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

Re: Fuzz, Numbers

2020-01-12 Thread Mike Yurlov via devel
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

Re: Fuzz, Numbers

2020-01-09 Thread Mike Yurlov via devel
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

Re: Fuzz, Numbers

2020-01-06 Thread Hal Murray via devel
> 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

Re: Fuzz, Numbers

2020-01-06 Thread Mike Yurlov via devel
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

Re: Fuzz, Numbers

2020-01-02 Thread Hal Murray via devel
]>> 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

Re: Fuzz, Numbers

2020-01-02 Thread Udo van den Heuvel via devel
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?

Re: Fuzz, Numbers

2020-01-02 Thread Hal Murray via devel
>> 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.

Re: Fuzz, Numbers

2020-01-02 Thread Udo van den Heuvel via devel
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

Re: Fuzz, Numbers

2020-01-02 Thread Hal Murray via devel
> 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

Re: Fuzz, Numbers

2020-01-02 Thread Udo van den Heuvel via devel
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 ==

Re: Fuzz, Numbers

2020-01-02 Thread Hal Murray via devel
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

Re: Fuzz, Numbers

2019-12-31 Thread Hal Murray via devel
> 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

Re: Fuzz, Numbers

2019-12-30 Thread Mike Yurlov via devel
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

Fuzz, Numbers

2019-12-28 Thread Hal Murray via devel
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