Re: Increasing scan rate to 10 kHz

[Till Straumann <strauman@slac.stanford.edu>]

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