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: Dirk Zimoch <[email protected]>
To: "Hill, Jeff" <[email protected]>
Cc: EPICS Core Talk <[email protected]>, Eric Norum <[email protected]>
Date: Fri, 08 Jun 2012 18:17:05 +0200
Hi all,

Rounding up 0.000001 is 1, but rounding up 0.0 is 0. So what's the problem with zero-sleeps? Always round up means round up 0 to 0.

Dirk


Hill, Jeff wrote:
Ø Furthermore, I feel that no one would be (should be) calling epicsThreadSleep if they

Ø  wanted no amount of slumber.

So of course on certain, but not all, OS if one requests a sleep of zero then this yields to threads

of same priority. I have also never used that feature in portable code BTW.

Nevertheless, we might decide for epicsThreadSleep (double seconds).

seconds <= 0.0 implies an OS specific sleep of zero ticks.

0.0 > seconds <= 1.5 ticks implies an OS specific sleep of one tick.

1.5 > seconds <= 2.5 ticks implies an OS specific sleep of two ticks.

.

.

.

Whatever is decided, we certainly need to document this, and keep

all of the OS specific implementations consistent.

Jeff

*From:* Hill, Jeff
*Sent:* Friday, June 08, 2012 9:05 AM
*To:* Hill, Jeff; 'Eric Norum'; 'Ralph Lange'
*Cc:* 'EPICS Core Talk'; 'Dirk Zimoch'
*Subject:* RE: epicsTimer and rounding

Ø 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.

BTW, it occurred to me even yesterday (and probably before) that a good idea would

be to subtract the one half of a tick from the delay, to the next timer expiration, returned

from epicsTimer::process instead of subtracting this one half tick amount from the expiration

time stored in all of the timer objects.

This would have two beneficial impacts.

o The timer would never be allowed to expire early, as verified using epicsTime::getCureent().

o We can still make adjustments to this returned delay amount to get the wakeup to occur as

close as possible to the correct time on average.

I was thinking about this alternative even yesterday, but there is a hitch. What does one do if

waking up between zero and one half of a tick too early that doesn’t consume cpu or delay

timer expiration by much worse - between 1 tick <= delay <= 2 ticks.

So the bottom line is that, before sending my message today and yesterday, I considered the

above alternative and rejected it, due to concerns about wasted cpu.

PS: Note that if we don’t allow a timer to expire as much as one half tick too early then we

will also be obliged to accept that a timers will expire on average one half of a tick too late.

Nevertheless, I am happy to implement that alterantive if this what everyone wants.

PPS: I still think that we should make all of the epicsThreadSleep OS specific implementations

consistent WRT sleeps requested in seconds less than one half of a tick. Furthermore, I feel

that no one would be (should be) calling epicsThreadSleep if they wanted no amount of slumber.

PPPS: Ralph’s issue might also be resolved by deciding _/not/_ to subtract out the one half tick

from the timer expiration time if the requested timer delay is less than one tick. This additional

overhead would be necessary only if the epicsThreadSleep is allowed to interpret sleeps requested

less than one half of a tick as no sleep.

Jeff

*From:* Hill, Jeff
*Sent:* Friday, June 08, 2012 8:24 AM
*To:* 'Eric Norum'; Ralph Lange
*Cc:* EPICS Core Talk; Dirk Zimoch
*Subject:* RE: epicsTimer and rounding

Ø  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:* [email protected] <mailto:[email protected]> [mailto:[email protected]] *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
[email protected] <mailto:[email protected]>






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 Andrew Johnson
Next: Re: epicsTimer and rounding Andrew Johnson
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: "spinlock" API Michael Davidsaver
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 ·