In general, you want your duity cycle to be faster than the PM's sampling rate.

To mimic real things, block on a Kernal object. This is normally the file or whatever that it needs to complete. But make it a "waitable timer" and set it to go off at a precise time. So your loop would chew CPU for so many quantums, then block for so many. Look up the quantum value (how long a timeslice is), and use high-precision timing primitives rather than localtime, since you must get an order of magnitude (or two) more granularity.

The waitable timer is specified to milisecond resolution. The native 64-bit time value (GetSystemTimeAsFileTime) is updated once a quantum, so you can watch it jump if you are reading it in a loop. That tells you what the timeslice size is, too!

A quick check:

use strict;
use warnings;
use Win32::API;

my $f= new Win32::API ('Kernel32.dll', 'GetSystemTimeAsFileTime', ['P'
+], 'V');
my $buffer= 'x'x8;  #8 byte value

for (1..100000000) {
   $f->Call ($buffer);
   }
# printf "%vx\n", $buffer;
[download]

under PermMon shows that it does stay in User mode. That is, the constant calling to GetSystemTimeyadayada doesn't mess things up by constantly switching to kernel mode. Is should be simple, if the internal variable is simply accessed and returned.

I'm getting roughly 300,000 iterations per second, which is quite enough to get high-granularity: spin for a few miliseconds, block for a few miliseconds.

—John