Timer Objects -- execution frequency limits?

Hi,

I am trying to use a Timer object to make an API call to an external library every so often (~fractions of a second).

t = timer;
set(t,'ExecutionMode','fixedDelay','BusyMode','drop','Period',0.005);
t.TimerFcn = @my_callback_fcn;

While I don't need precise control over the instantaneous period, and I am ok with executions getting dropped once in a while, I need the average period to be around 5 milliseconds (specified above).

However, when I run the above timer on my Matlab R2009b (on Win XP sp2) with a dummy callback (nothing inside my_callback_fcn), it takes at least ~16 ms between successive timer executions i.e. the frequency of calling TimerFcn is about 60Hz.

Is the timer period something I can reduce to a value smaller than 16ms? Or is this a system limited value?

I would appreciate some feedback.

Thanks,

Sridhar

Answer 1

[Jan]

There is not hard limit in the timer frequency. The system speed limits the execution time of the callbacks and in consequence the frequency.

You could by a faster computer. In the comparisons I've seen in the net, Matlab runs remarkably faster under Linux.

Answer 2

[Walter Roberson]

In practice the system speed of modern desktop systems is not the key limiter of timer frequency.

Timers can be implemented by interrupt, by sleeping, or by polling.

For interrupts, the program (MATLAB itself) would request that an interrupt routine be called at a particular [usually relative] time. The limit in such cases is on the time taken to take a hardware interrupt and do a context switch. The time required on MS Windows systems to interrupt and context switch has been more or less unchanged since the days of NT4, and stands at about 50 microseconds (or less if context switches are not necessary.) 50 microseconds is a few orders of magnitude faster than Sridhar is seeing, so we can deduce that MATLAB is not using this mechanism.

sleeping is putting in an operating system request to be re-awoken at a particular [relative] time. The POSIX standard on this facility is a based upon a clock rate minimum of 60 clicks (ticks per second), with some OS going to 100, but hardly anyone going past that. Windows Media Timers occur at 64 Hz which is right in line with this, suggesting that the Windows Media Timers might be based upon this kind of timer.

I found pages that indicate that Windows 32 bit native time interrupt was only 18.2 Hz, which is a rate of a legacy time-of-day timer interrupt; this much like the POSIX timers in basic design, but at a rate slower than POSIX requires. http://www.codeguru.com/forum/archive/index.php/t-197347.html

Polling is an arrangement in which the software executes in a loop, checking the time at the top of the loop and executing any timers that have expired (that is, need to be fired), and then after those, going on to the regular work. There are aspects of how MATLAB handles timer interrupts that are consistent with this mechanism.

But what is actually used by interpreters such as MATLAB? It can be a mix. There might well be an interrupt timer fired by hardware, but usually the interrupt routine just sets a flag indicating that some timer has expired; when the interpreter loop hits that point in the cycle and finds the flag set, it services its interrupt queue. Why not just read the precision system timer each loop? Because reading the precision system time is a relatively slow operation, especially if you use an official operating system call instead of running with elevated privileges and reading the hardware timers at the program level. Checking a flag is fast.

Interpreters do not usually service extended interrupts through a direct hardware interrupt routine because interpreters usually have too much complex state to risk doing that.

Windows offers a High Precision Event Timer (HPET), which is a count-up device running at a minimum of 10 megahertz, and which goes off when the count matches the target time. I have found no evidence that MATLAB uses this timer for anything.

You may wish to examine this blog article which describes how MATLAB uses Windows cycle counters to measure elapsed time between events. Measuring elapsed time between events is a notably different activity than relative time timers or (especially) absolute time timers.

[Jan]

Thanks for this valuable information. +1

Answer 3

[Walter Roberson]

There are different ways to implement timers in operating systems. One of the possible mechanisms, the POSIX (Portable Operating System standard) mechanism, is indeed tied to 60 Hz. I find evidence that XP uses a 64 Hz timer.

Going beyond 60 Hz requires that the program use what-ever "High Accuracy Timers" are available on the specific operating system.

It is not clear from the documentation as to whether MATLAB uses the High Accuracy Timers or not, but historically it has not been uncommon in operating systems for those timers to roll over in a relatively small number of hours or days, historically making them unsuitable for longer intervals. If MATLAB was restricted in that way, it would seem more likely that Mathworks would have documented that fact, which leads me to suspect that MATLAB does not depend on such timers.... but I don't know.

Answer 4

[Sridhar]

Thanks for the clarification, guys.

As you point out, the minimum resolution on my mac (os x 10.5, which runs on a bsd kernel) appears to be ~1 ms.

t=timer; set(t,'ExecutionMode','fixedDelay','BusyMode','drop','Period',0.0001);

??? Error using ==> timer.set at 130 Cannot set Period property to be less than 0.001 seconds.

set(t,'ExecutionMode','fixedDelay','BusyMode','drop','Period',0.001); t.TimerFcn = @my_callback_fcn; start(t); stop(t); get(t, 'AveragePeriod')

ans =

    0.0012

So I'm guessing my original problem with the poor time resolution had to do with WinXP system clock update frequency (perhaps there is a way of changing this?). I wonder if there is a way for the Matlab Timer object to access the winxp high precision timers. Any thoughts? Thx.

Answer 5

[Quang Huy]

thanks. I'm so intersed in this problem.