I did a quick test on my MVME 5100 vxWorks 5.5 system.
1. increasing sysCklRate to 5000 (maximum that vxWorks lets me do)
-> CPU load went up from 2.0% to 2.6%
2. add a ".0002 second" scan rate
-> CPU load went up to 7.3%
3. put some records on the scan:
ai with "Soft Timestamp" support
calc to get time interval
calc to get maximum interval
-> CPU load went up to 27.0%
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000399947 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000399947 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000400066 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000399947 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000400066 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000199914 sec
DZ:TIMEDIFF 0.000200033 sec
DZ:TIMEDIFF 0.000399947 sec
DZ:TIMEDIFF 0.000200033 sec
After boot:
DZ:MAXTIMEDIFF 0.021000028 sec
After reset to 0 and and some wait:
DZ:MAXTIMEDIFF 0.000400066 sec
DZ:MAXTIMEDIFF 0.000600100 sec
Suddenly after some minutes:
DZ:MAXTIMEDIFF 0.002032518 sec
This does not look very promising.
(DB is attached.)
Dirk
On 08.01.2014 17:20, 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
record (ai, "DZ:TIMESTAMP")
{
field (DTYP, "Soft Timestamp")
field (SCAN, ".0002 second")
field (PREC, "9")
field (EGU, "sec")
field (FLNK, "DZ:TIMEDIFF")
}
record (calc, "DZ:TIMEDIFF")
{
field (INPA, "DZ:TIMEDIFF.B")
field (INPB, "DZ:TIMESTAMP")
field (CALC, "A?B-A:0")
field (PREC, "9")
field (EGU, "sec")
field (FLNK, "DZ:MAXTIMEDIFF")
}
record (calc, "DZ:MAXTIMEDIFF")
{
field (INPA, "DZ:TIMEDIFF")
field (INPB, "DZ:MAXTIMEDIFF")
field (CALC, "A>B?A:B")
field (PREC, "9")
field (EGU, "sec")
}
- References:
- Re: Increasing scan rate to 10 kHz Andrew Johnson
- Re: Increasing scan rate to 10 kHz Till Straumann
- Navigate by Date:
- Prev:
Re: Agilent 33522A Function / Arbitrary Waveform Generator Michael Johnson
- Next:
Re: Increasing scan rate to 10 kHz Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Increasing scan rate to 10 kHz Till Straumann
- Next:
A call to 'assert(capacity != 0)' by thread Emmanuel Mayssat
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|