Fuzz, Numbers

Mike Yurlov ntp at kaluga.net
Mon Jan 13 12:18:50 UTC 2020


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 does not simple, especially on many 
OS. www daemons do it, but it does not need so fast reply time (on the 
other hand, tsp is harder, udp no connection setup required).

2. external "balancer/cacher" daemon like rsntp. For example child 
threads can use SHM linux shared memory (or something like this) and 
read value from "main" ntp process. I guess it can be fast. Even if you 
cache time value in child thread for ms, it still be very useful. (Or 
its "caching time" may be subtracted for greater accuracy). I guess 
overloaded NTS task is not so much "nanoseconds" precision time as to 
serve huge number of customers. So this mode will be good solution too.

--
Mike

> 13.01.2020 11:54, Hal Murray:
>> 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 who want to process hundreds of thousands of requests per  second
>>> (like 'national standard' servers) you can use multithreading and  multiply
>>> power of server.
>> The current code isn't setup for threads.  I think with a bit of work, we
>> could get multiple threads on the server side.
>>
>> On an Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
>> I can get 330K packets per second.
>> 258K with AES CMAC.
>> I don't have NTS numbers yet.
>>
>>
>>
>>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200113/09297d36/attachment.htm>


More information about the devel mailing list