g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: epicsTimer and rounding
From: Ralph Lange <Ralph.Lange@gmx.de>
To: EPICS Core Talk <core-talk@aps.anl.gov>
Cc: Dirk Zimoch <dirk.zimoch@psi.ch>
Date: Fri, 08 Jun 2012 15:35:54 +0200
Hi Jeff,

On 06.06.2012 18:15, Hill, Jeff wrote:
> I made that tweak (subtracting one half of the quantum from the timer expiration time) when running the tests and attempting to optimize measured timer expiration as close as possible to the specified expiration time (on average). 
> [...]

OK, I understand the argumentation.

Let me demonstrate the problem from the application side:

I am interfacing to a serial device on RS-485.
According to the device's spec, after sending a message, I have to make
sure there is at least a 4ms break before sending the next message.
I am configuring StreamDevice to wait for 5ms after the message.
StreamDevice sets up an epicsTimer for 5ms. On Linux, the clock tick is
usually 10ms, so epicsTimer substracts 5ms and calls epicsThreadSleep(0.0)
The posix implementation of epicsThreadSleep calls nanosleep asking for
a 0 delay, and gets a 0 delay.
The next message is written on the RS-485 with zero delay (seen on a
scope), the device barfs, communication goes haywire.

I do see the beauty of statistical correctness, but this behavior is
plain wrong.

> Related to this issue is of course what goes on in epicsThreadSleep. Note that, at least the windows version (see attached code at the end of the email), does make certain of two things. Presumably similar code exists for each of the OS specific implementations.
> 1) a sleep requested, less than one quantum, will be rounded up to one quantum (the OS also probably makes this check)
> 2) rounding occurs from the specified floating point seconds to the nearest number of quantums by adding .5 to the floating point number of quantums just before integer truncation.
> In your email you were worried that a sleep close to the quantum will be off by 100% because of the one half quantum subtraction, but I believe that all OS specific implementations force a sleep of less than a quantum to be actually one quantum.

Only for requested sleeps greater than zero.
Requested epicsTimer sleeps of half a quantum or less will - after the
half quantum subtraction - request from the OS a sleep of zero, which
will not be rounded up by the OS specific implementation. No sleep at
all. That is an error of 100%.

> So Ralph makes the point that if the user ask for delay fff.fff then there should never be a timer expiration occurring that is less than a delay of fff.fff. So this is the crux of the matter isn't it; should we make the timer expiration delay as close as possible to the user's request on average (that's good for time algorithmic code such as a pid) or should we guarantee timer expiration delay is never less than the delay specified (maybe because we are concerned about cpu use with very short timer delays but see the previous paragraph).

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.


Re: epicsTimer and rounding Kasemir, Kay
Re: epicsTimer and rounding Eric Norum
epicsTimer and rounding Ralph Lange
RE: epicsTimer and rounding Hill, Jeff

Navigate by Date:
Prev: "spinlock" API Michael Davidsaver
Next: Re: epicsTimer and rounding Kasemir, Kay
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: RE: epicsTimer and rounding Hill, Jeff
Next: Re: epicsTimer and rounding Kasemir, Kay
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·