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  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: epicsTimer and rounding
From: "Hill, Jeff" <johill@lanl.gov>
To: Eric Norum <eric@norum.ca>, Ralph Lange <Ralph.Lange@gmx.de>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>, Dirk Zimoch <dirk.zimoch@psi.ch>
Date: Fri, 8 Jun 2012 14:24:13 +0000

Ø  The posix implementation of epicsThreadSleep calls nanosleep

Ø  asking for a 0 delay, and gets a 0 delay.

 

This is certainly inconsistent with the windows implementation which (intends) to round

any floating point seconds sleep requested of less than one tick to a tick. Rounding sleeps

of between 0 and .5 seconds to no sleep definitely seems wrong to me. We should probably

clarify what behavior should be implemented by each OS specific stub in the application

developers guide, and then make all of them consistent?

 

Ø  I've never encountered a 'sleep/pause/nap/delay' function that could return early.

 

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.

 

I will certainly go with whatever the consensus ends up being.

 

Jeff

 

From: core-talk-bounces@aps.anl.gov [mailto:core-talk-bounces@aps.anl.gov] On Behalf Of Eric Norum
Sent: Friday, June 08, 2012 7:46 AM
To: Ralph Lange
Cc: EPICS Core Talk; Dirk Zimoch
Subject: Re: epicsTimer and rounding

 

On Jun 8, 2012, at 6:35 AM, Ralph Lange wrote:


It is application dependent. Short sleeps are usually intended as waits,
so the application assumes it will wake up no earlier than after the
requested time. This is why the OS specific sleep functions always round
up, never down. And this is why I think the epicsTimer should behave the
same way.

In case an application wants a statistically optimized behavior, it can
easily get the quantum and do the subtraction itself.

I know this is symmetric (the application could add half a quantum when
it wants the round-up behavior), but I would strongly suggest that the
semantics of the epicsTimer follow the semantics of all reasonable OS's
sleep implementations, and always round up to the next quantum.

 

I agree with Ralph 100% 

I've never encountered a 'sleep/pause/nap/delay' function that could return early.

-- 
Eric Norum
eric@norum.ca




 


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

Navigate by Date:
Prev: Re: epicsTimer and rounding Eric Norum
Next: Re: epicsTimer and rounding Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: epicsTimer and rounding Eric Norum
Next: Re: epicsTimer and rounding Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
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 ·