EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: epicsTimer and rounding
From: Ralph Lange <[email protected]>
To: EPICS Core Talk <[email protected]>
Cc: Dirk Zimoch <[email protected]>
Date: Fri, 08 Jun 2012 17:04:52 +0200
On 08.06.2012 16:24, Hill, Jeff wrote:

Next question; If we decide that a sleep of less than one tick should be a sleep of one tick, then

perhaps Ralph’s issue is arguably caused by an issue in the posix implementation of

epicsThreadSleep instead of in epicsTimer. Fixing only posix timer (and any other inconsistent

implementations) would presumably be an optimal solution where Ralph’s issue is solved and

also periodic timers can remain more statistically accurate (on average)? Note that the epicsTimer

class _is_ used to schedule the scan threads, ca beacons, etc.


That will not fix my issue.
If my application requests 15ms sleep, 10 are not acceptable.
If my application requests 25ms sleep, 20 are not acceptable.
...

IMHO:
1. epicsTimer should not round.
2. epicsThreadSleep should always round up, following usual sleep/pause/nap/delay semantics, without forcing a sleep of one quantum when 0.0 is requested.
This matches the existing API specification. Currently, Windows, vxWorks, and RTEMS implementations do not follow the API spec, the posic implementation is correct.
2. The epicsTimer behaviour should be documented.
3. An application that wants statistically optimized delays may subtract half a quantum when setting up the epicsTimer. This should be mentioned in the documentation, and scan threads, ca beacons etc. should use this method. (Maybe add a "statistically more accurate" variant of the start method to the epicsTimer API for convenience.)

Cheers,
Ralph


Replies:
Re: epicsTimer and rounding Eric Norum
References:
epicsTimer and rounding Ralph Lange
RE: epicsTimer and rounding Hill, Jeff
Re: epicsTimer and rounding Ralph Lange
Re: epicsTimer and rounding Eric Norum
RE: epicsTimer and rounding Hill, Jeff

Navigate by Date:
Prev: RE: epicsTimer and rounding Hill, Jeff
Next: RE: epicsTimer and rounding Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: epicsTimer and rounding Hill, Jeff
Next: Re: epicsTimer and rounding Eric Norum
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·