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: "Kasemir, Kay" <kasemirk@ornl.gov>
To: Ralph Lange <Ralph.Lange@gmx.de>, EPICS Core Talk <core-talk@aps.anl.gov>
Cc: Dirk Zimoch <dirk.zimoch@psi.ch>
Date: Fri, 8 Jun 2012 09:44:30 -0400
Hi:

I think Ralph's example of how 'sleep' is used is correct.
Must sleep at least as long as requested.

What Jeff describes is a periodic timer.

The Java Timer class nicely offers both, allowing to
a) schedule a task after some delay, with at least that delay
b) schedule a periodic task, where the period between invocations might be
'squeezed' to achieve statistical correctness in the long run


These are different scenarios, and one epicsThreadSleep() can't do both.
The name epicsThreadSleep suggests to me that it's meant to be used for
the 'sleep', not for scheduling a periodic task.
That would require a different API like
 
epicsThreadPeriodic(...)


Thanks,
Kay




On 6/8/12 09:35 , "Ralph Lange" <Ralph.Lange@gmx.de> wrote:
>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.
>
>Cheers,
>~Ralph
>



Replies:
Re: epicsTimer and rounding Andrew Johnson
References:
Re: epicsTimer and rounding Ralph Lange

Navigate by Date:
Prev: Re: epicsTimer and rounding Ralph Lange
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 
Navigate by Thread:
Prev: Re: epicsTimer and rounding Ralph Lange
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 
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 ·