2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: epicsTimer and rounding |
From: | "Hill, Jeff" <[email protected]> |
To: | "Hill, Jeff" <[email protected]>, Eric Norum <[email protected]>, Ralph Lange <[email protected]> |
Cc: | EPICS Core Talk <[email protected]>, Dirk Zimoch <[email protected]> |
Date: | Fri, 8 Jun 2012 15:05:13 +0000 |
Ø
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
Ø
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]]
On Behalf Of Eric Norum On Jun 8, 2012, at 6:35 AM, Ralph Lange wrote:
I agree with Ralph 100% I've never encountered a 'sleep/pause/nap/delay' function that could return early. -- |