xPC Target in Freerun mode: extra long sample time

I run a quasi-empty model in xPC Target Freerun mode.

To approximately evaluate how much the sample time is constant, I insert in the model an S-function which outputs the system time:

static void mdlOutputs(SimStruct *S, int_T tid) {

#ifndef MATLAB_MEX_FILE

    real_T *y;

    y=ssGetOutputPortSignal(S,0);

    y[0] = xpcGetElapsedTime( (xpcTime *)NULL );

#endif

}

I have logged the output signal of this S-function and I have plotted the difference (by diff matlab function) for visualizing the approximate sample time: I found that the sample time is very little and quite constant for almost all the samples (its value is 1.2e-6 sec) except for some regulars extra long sample (9.9e-3 sec) which occur every 100 samples.

I write to ask why this happens and how it is possible to solve this problem.

Thank in advance you for your help

Best regards

Answer 1

[Suneesh]

1. There is a shipped block called 'Task Execution Time' that does exactly what you did.
2. The sporadic spikes are usually due to:

• Cache misses when loading states into memory at the beginning of model execution
• Cache misses when background tasks move lots of data
• System Management Interrupts (SMI)

Please see:

http://www.mathworks.com/matlabcentral/answers/91970-what-is-the-definition-of-task-execution-time-%28tet%29-and-what-does-it-measure-in-xpc-target

Answer 2

[Rajiv Ghosh-Roy]

In addition to the other replies, Freerun mode simply runs the model as fast as it can and does not attempt to get real-time (== matches wall-clock) performance. In this mode, every so often, xPC Target will stop running the model and service other things such as network communication, screen updates, etc. This is why it takes a differing amount of time.

Freerun mode is not intended to have any determinism as to intervals between running each sample. For this, you should use Real-Time mode.

Answer 3

[James Brown]

Check your target machine's BIOS to ensure that legacy USB is turned off. Legacy USB will occasionally grab close to a msec of the machine's time.