Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: generalTime/epicsTimeGetCurrent and casr questions
From: Michael Davidsaver via Tech-talk <tech-talk@aps.anl.gov>
To: "Johnson, Andrew N." <anj@anl.gov>, "Layne (US), William C" <william.c.layne@boeing.com>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: 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

Replies:
Re: generalTime/epicsTimeGetCurrent and casr questions William Layne via Tech-talk
References:
generalTime/epicsTimeGetCurrent and casr questions Layne (US), William C via Tech-talk
Re: generalTime/epicsTimeGetCurrent and casr questions Mark Rivers via Tech-talk
Re: generalTime/epicsTimeGetCurrent and casr questions Johnson, Andrew N. via Tech-talk

Navigate by Date:
Prev: RE: generalTime/epicsTimeGetCurrent and casr questions Mark Rivers via Tech-talk
Next: Re: generalTime/epicsTimeGetCurrent and casr questions William Layne via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: RE: generalTime/epicsTimeGetCurrent and casr questions Mark Rivers via Tech-talk
Next: Re: generalTime/epicsTimeGetCurrent and casr questions William Layne via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 13 Mar 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·