Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <[email protected]> · Sun, 10 Mar 2019 19:19:41 -0700

On 3/9/19 2:17 PM, Johnson, Andrew N. via Tech-talk wrote:
> William — regarding your question about generalTime, I believe Michael Davidsaver has some ideas about rewriting the generalTime code to try and reduce the contentions on that mutex (it’s probably the one you named but I don’t have the code in front of me to check right now). I don’t know how far he has got with that if anywhere though.

Yes, 'gtPvt.timeListLock' is the one I was thinking of.  Though 'onceLock' in posix/osdThread.c,
and whatever is behind pthread_once() will also contribute.  There is a lot going on behind
epicsTimeGetCurrent().

This kicked something loose in my memory.  I've refreshed an old patch
which adds a global flag to short-circuit the bulk of the overhead in
epicsTimeGetCurrent() in the common case of only the default provider.

https://code.launchpad.net/~epics-core/epics-base/+git/Com/+merge/364220

Which could go along with my previous work to replace calls to fetch current
time with calls to fetch monotonic time.

https://code.launchpad.net/~epics-core/epics-base/+git/Com/+merge/361380

I was tempted to speculate that this might be slightly faster.  It's good that
I refrained.  As currently implemented on Linux.  epicsMonotonicGet() is calling
clock_gettime() with CLOCK_MONOTONIC_RAW which at least on my laptop (Linux 4.19)
appears to be surprisingly slower to call than CLOCK_REALTIME, or indeed CLOCK_MONOTONIC.

Time needed to make 1000000 calls to clock_gettime() in a loop w/

CLOCK_MONOTONIC_RAW  ~500ms

CLOCK_REALTIME and CLOCK_MONOTONIC  ~35ms

CLOCK_MONOTONIC_COARSE and CLOCK_REALTIME_COARSE  ~10ms

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System