Multimedia timer callback function
Pawelq
fail to observe any of the group's rules - I do not know them. Yet.
I am writing a Win32 application for WinXP which should poll data from
the LPT port every 1ms (would be nice to have a shorter interval, but I
know I should be realistic).
On idea is to use a multimedia timer (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_timesetevent.asp
).
I am only unsure about one thing. In what context is the callback
function called? Do I need to use critical sections to exchange data
with my application?
I have also found two other solutions based on clever usage of threads:
http://www.codeguru.com/Cpp/W-P/system/timers/article.php/c5759
http://espresso.cs.up.ac.za/publications/janno_grobbler_etal_saicsit2005.pdf
The latter seems particularly well investigated and based on thorough
research (which shows, among other things, that the multimedia timer is
quite unreliable when the requested interval is 1 ms).
I was wondering if somebody has tried any of these solution, and do you
think they are feasible?
Thanks in advance for any replies,
Pawel
Scott Moore
> Hi everybody, this is my first post on this group. Please forgive if I
> fail to observe any of the group's rules - I do not know them. Yet.
>
> I am writing a Win32 application for WinXP which should poll data from
> the LPT port every 1ms (would be nice to have a shorter interval, but I
> know I should be realistic).
>
> On idea is to use a multimedia timer (
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_timesetevent.asp
> ).
>
> I am only unsure about one thing. In what context is the callback
> function called? Do I need to use critical sections to exchange data
> with my application?
Yes. The multimedia timer is very close to being an interrupt. There are
restrictions on what system services you can call during the callback.
>
> I have also found two other solutions based on clever usage of threads:
>
> http://www.codeguru.com/Cpp/W-P/system/timers/article.php/c5759
>
> http://espresso.cs.up.ac.za/publications/janno_grobbler_etal_saicsit2005.pdf
>
> The latter seems particularly well investigated and based on thorough
> research (which shows, among other things, that the multimedia timer is
> quite unreliable when the requested interval is 1 ms).
I disagree. The multimedia timers got a reputation for problems in "old"
windows, but in Win 2000 and WinXP, I have found them to be quite reliable.
Scott Moore
I read the second paper. It has a few flaws, but I don't disagree with its
conclusion, which is that you are going to see variance of 500us in the
multimedia timer. One of the flaws in the article is that they don't measure
instantaneous variation, which is equally important, and didn't discuss
how they performed the measurements. This latter factor is important.
They need to prove that whatever mechanism they used to indicate the
result was not a factor. For example, if the software fired the timer, then
compared it to the ACPI timer, that very observation itself could introduce
variance.
Another flaw, IMHO, is their frequent quoting of Wikipedia, which is
essentially quoting noise. Wikipedia is a good resource, but it can be
edited by anyone, with no responsibility for the facts inserted there.
It can in fact be completely wrong one day, and right the next, as
people alternately damage and repair it. At the very least, quoting it
is flawed since it has no record - it can and does change since it was
quoted.
The "solution" given, that of using the MM timer to arrive at a point just
before the actual time to measure, then POLL the ACPI timer to achieve
50us accuracy, begs several important questions:
1. Do you actually NEED that kind of accuracy ? The method wastes CPU time
by polling (if even only for a short time).
2. What good is that kind of accuracy when any operation done in the
context of Windows is going to vary more than the accuracy of the timer
you just created. I.e., if you have a task to do, like presenting frames
of video, or outputting a waveform to an audio device, the variation in
running that operation is going to be larger than the 50us accuracy you
thought you had. Windows is NOT a real time system, nor does it pretend
to be.
3. If Windows has low instantaneous variation, that may be all you need.
For example, audio or video is going to care more about IV than overall
accuracy. Trying to get better accuracy in such an application would not
help you.
Things to think about.
Scott Moore
The other issue that occurs to me, and the author of the second paper
covered it, is that the algorithim of firing the MM timer, then waiting
in a loop on the ACPI timer is itself inherently unreliable under windows.
That loop could itself be interrupted by a task switch.
The author brought up a good point, the simplest way to defeat the system
is to run two instances of the same "accurate" program, in which case
these hard ACPI polling loops will eventually interfere with each other.
Further, the author was measuring up to 10% of the CPU total time LOST
to this polling technique, so it is inherently wasteful.
Hardware makers who need this kind of accuracy set up interrupts inside
a windows driver, and perform the timing operation completely outside of
windows. Trying to use windows to get this kind of accuracy is inherently
flawed, IMHO.
--
Samiam is Scott A. Moore
Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas
Good does not always win. But good is more patient.
Pawelq
Despite my poor programming skills I was able to repeat the second
paper authors' tests. I compared the multimedia (MM) timer vs. the
authors' Thread Induced Waitable (TIW) timer. My results were similiar
to their results.
I ran each timer for about 5 seconds on WindowsXP, Pentium 4HT 3 GHz.
The timing was collected in a callback function by querying the
performance counter, increasing an index, and storing the counter value
in a pre-prepared array at the index.
The callback function was the same for both timers: the one required by
the MM timer, for the TIW timer the parameters were set to 0.
I examined the time periods between consecutive timer 'ticks', after
removing start and end peculiarities (see below). I assumed that a time
period <=1.25 ms is 'accurate'.
When I set the MM timer to 1 ms, about 97.6% of intervals were accurate
(0.794-1.084 ms), but the rest (2.4%) of outcomes were 1.88-1.99 ms.
The plot looked very much like the one in the paper.
The TIW timer produced 99.89% accurate (<=1.25 ms) results. The most
important departure from the accuracy was a single occurence of three
consecutive wrong intervals of 2 ms, 0.2 ms, 1.6 ms. This looks like a
desynchronization of the threads.
Except that, there were three intervals between 1.25 and 1.5 ms, and a
few minor deviations from 1 ms. Overall, standard deviation of
intervals was more than 6 times smaller for TIW than for MM timer
(0.022 ms vs. 0.15 ms). The median of intervals was closer to 1 for TIW
than for MM (1.0002 ms vs. 9.77 ms).
The "peculiarities" which I mentioned above were: a single 3-ms
interval ending the TIW series and five 4-6 microsecond intervals
starting the MM series. I did not take them into account because they
were apparently related to enabling and disabling of the timers.
I did not measure the procesor time directly, just looked in Task
manager. It showed 0% for MM timer and 2-3% for the TIW timer.
>then waiting
>in a loop on the ACPI timer is itself inherently unreliable under windows.
>That loop could itself be interrupted by a task switch.
I had an idea (maybe a silly one) that it could be prevented (at least
to some extent) by raising the threads' priority. I tried it.
When I ran the threads as TimeCritical, the wasted processor time (as
measured with Task Manager) did not increase noticeably and was still
at 2-3%. But the outcomes of the TIW timer improved much. In three
consecutive 5-s runs, the accuracy (as defined above) was 100% (after
removing the final 3ms interval which occurred all the times, and the
initial 1.6 ms interval, which occurred once). The standard deviation
was around 0.0012 ms, about 90-130 times smaller than for MM. Apparent
thread desychronization never occurred, and the highest interval value
was around 1.06 - 1.1 ms.
For comparison, repeating the MM timer measurements showed very
consistent results: 97.6% of intervals <=1.25 ms, and standard
deviation 0.15 ms.
It seems to me, that the idea presented in the paper is not bad and
might be useful for some purposes, that is, when high accuracy is
desirable and we don't care about few % of the processor time being
wasted.
Scott Moore
A good piece of research. Now what happens when you run two instances of
that program at once ? Three ?
Lucian Wischik
>The author brought up a good point, the simplest way to defeat the system
>is to run two instances of the same "accurate" program, in which case
>these hard ACPI polling loops will eventually interfere with each other.
Ha ha! For some reason I found this counterexample to be hilarious!
--
Lucian
Pawel Kusmierek
>that program at once ? Three ?
This can be easily prevented, but of course one cannot prevent running
more two or three different applications which use the same timer
mechanism. And this would mean trouble.
I think that for general purpose and general audience applications the
multimedia timer is better. It is accurate enough for most purposes,
and it would work well in typical Windows circumstances, with many
other applications (possibly using timers as well) and services
working.
The TIW timer may be good for specialized applications, which run in
heavily tuned systems, with many services disabled, fancy visual
effects disabled, no network connections and of course no other
applications run concurrently. Which is how I am going to use my
application.
Having said that, I have to add that the tests described above were run
in a non-tuned system, with five IE windows, one Excel window, a
Notepad window, and maybe something else running in the background. And
a quite huge programming environment was running as well: I run my test
application from within the programming environment.
Pawel Kusmierek
Scott Moore
Sounds like you have done your homework. Good luck.