EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Increasing scan rate to 10 kHz
From: Andrew Johnson <[email protected]>
To: Till Straumann <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Wed, 8 Jan 2014 11:37:55 -0600
Hi Till,

The periodic scan threads use epicsEventWaitWithTimeout() to wait for
their next tick — we need to be able to wake up those threads on demand
so the IOC doesn't have to spend up to 10 seconds (or whatever is the
longest scan period) waiting for those threads to shut down when the
user types exit.

On the Posix architectures the wait occurs in pthread_cond_timedwait(),
on RTEMS in rtems_semaphore_obtain(), on VxWorks in semTake(), and on
Windows in WaitForSingleObject(). The Posix API provides nanosecond
resolution, and even the ability to choose which clock to use although
we don't set that ourselves and that ability may not be supported on all
architectures. Note that our Posix code runs on MacOS and Solaris as
well as Linux.

For RTEMS and VxWorks the wait time is expressed in system clock ticks.
Increasing the tick rate to use a finer time resolution results in more
CPU time spent handling the tick interrupt, as Dirk has shown; that is a
trade-off the user can make though. On Windows the delay time is given
in milliseconds so the maximum scan rate there would be 1KHz, assuming
that the OS could cope.

Personally I think that trying to support scan rates faster than about
1KHz at most is never going to be reliable and probably isn't worth
spending much time on, but I'm always open to code contributions that
prove me wrong (as long as they're sufficiently portable).

- Andrew

On 01/08/2014 10:36 AM, Till Straumann wrote:
> It should be noted that with RT_PREEMPT the real-time threads
> all execute in *user-mode*. They can run side-by-side with other
> low-priority stuff in the same process and still get scheduled as
> needed, preempting any other (lower-priority) thread or process
> with low latency. Hence it is not necessary to play special tricks
> with putting high-priority code into kernel modules etc.
> 
> - Till
> 
> 
> On 01/08/2014 08:20 AM, Till Straumann wrote:
>> On 01/07/2014 02:19 PM, Andrew Johnson wrote:
>>> Periodic scans are quite complicated, since they rely on the
>>> underlying operating system to implement a delay timer and reschedule
>>> the scan thread after the specific delay has elapsed. Most OSs don't
>>> provide high accuracy delay scheduling, so I don't expect we will ever
>>> be able to run periodic scan threads at 10KHz. - Andrew
>> As a matter of fact I don't think that 10kHz periodic scans are a big
>> problem for something like RTEMS
>> or linux (with RT_PREEMPT) on a reasonably fast CPU.
>>
>> I just used a simple 'clock_nanosleep' based loop (based on code by
>> windriver, modified by myself)
>> which does something like
>>
>> while ( 1 ) {
>>       /* get current time */
>>         clock_gettime( CLOCK_MONOTONIC, &wakeup );
>>       /* compute wakeup time 100us from now   */
>>         timespec_add_100us( &wakeup );
>>       /* sleep until wakeup time      */
>>         clock_nanosleep( CLOCK_MONOTONIC, TIMER_ABSTIME, &wakeup, NULL );
>>       /* see when we actually woke up */
>>         clock_gettime( CLOCK_MONOTONIC, &now );
>>       /* missed = now - wakeup        */
>>         timespec_diff( &missed, &now, &wakeup );
>>
>>       compute_statistics( &missed );
>> }
>>
>> for a bunch of threads (using the SCHED_FIFO scheduler).
>>
>> On my laptop (vanilla kernel, no RT_PREEMPT) I observe worst-case
>> 'missed' deadline of several milli-seconds
>> but even on that system the running average is between 5us..50us.
>>
>> On a kernel patched with RT_PREEMPT I get a worst-case missed deadline
>> by ~10us (average around 3-4us)
>> after running for a few minutes (on a not heavily loaded intel core
>> i7-2655LE, 2.2 GHz).
>>
>> I would expect RTEMS/vxWorks to even perform a bit better.
>>
>> - Till
> 

-- 
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Replies:
Re: Increasing scan rate to 10 kHz Till Straumann
References:
Re: Increasing scan rate to 10 kHz Andrew Johnson
Re: Increasing scan rate to 10 kHz Till Straumann
Re: Increasing scan rate to 10 kHz Till Straumann

Navigate by Date:
Prev: Re: Increasing scan rate to 10 kHz Dirk Zimoch
Next: Re: Increasing scan rate to 10 kHz Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Increasing scan rate to 10 kHz Till Straumann
Next: Re: Increasing scan rate to 10 kHz Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·