Experimental Physics and
Industrial Control System

"Konrad, Martin via Core-talk" <[email protected]> · Wed, 15 May 2019 15:21:58 +0000

Hi Michael,
> So the shortest timer is expiring, and being restarted,
> most frequently.  The worst case of the insertion
> sort is the most common...
In this particular use case. Note that there are other use cases where
many timer instances get created with the same duration. In these cases
searching the list backwards is faster. I'm investigating different
schemes for managing the timers that perform well for both use cases.

> The attached patch adds trace point to timer.cpp in libCom
> when a timer is started.  It shows how many step the insertion
> sort had to make, and the total # of timers.
Your histogram looks very useful. I'll see if I can get it going on my IOC.

Yesterday, I actually patched Base to measure the max. number of timers
in the queue for my Asyn use case: ~30,000. My IOC has ~55,000 records.
Assuming ~50,000 perform I/O through StreamDevice in a 1 s time window
(worst case if all scan threads kick in within this second) this adds up
to a few seconds of CPU time just searching the list of timers
(searching a std::list with 30,000 elements takes ~50 us on my laptop).

I found a paper describing several algorithms for timer facilities [1].
Currently libCom is implementing what is described as "scheme 2". It
also describes algorithms that should perform better in multi-threaded
environments (scheme 5, 6, 7). I think I need to get a clear picture of
how the EPICS timer facilities are being used before I can say which
scheme might be best.

-Martin

[1] http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf

-- 
Martin Konrad
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824-1321, USA
Tel. 517-908-7253
Email: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System