Re: generalTime/epicsTimeGetCurrent and casr questions

[William Layne via Tech-talk <tech-talk@aps.anl.gov>]

Excuse the second email address.

Mark - Our situation looks like what is happening on "Ferrari". I'm guessing the CA API is allowing the user to continually create channels. Seems like both the IOC and CA API should be able to know that they have already subscribed. I'll go take a look at how our users are subscribing.

David - Thanks for that info, didn't know about pthread_once doing something similar. I'll stub out epicsTimeGetCurrent to call my provider and see what effect that has. 

Will report back findings and possibly have more detailed questions after some testing sessions tomorrow.

Thanks,

Casey

On Sun, Mar 10, 2019, 10:20 PM Michael Davidsaver via Tech-talk <tech-talk@aps.anl.gov> wrote:

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