Note that the thread affinitization recommendation for
QueryPerformanceCounter has nothing to do with differing clock speeds across
multiple CPUs but rather ‘BIOS / HAL bugs’; otherwise read ‘shame on your
AMD’
To the OP:
Note that while there are some legitimate uses for Sleep, your problem does
not appear to be one of them. I am not sufficiently clear as to what you
are actually doing to say anything for sure, but if you have a driver / code
that works when fed data at ‘slow’ speed and fails when fed data at ‘high’
speed, then most likely you have a bug. note that I differentiate between
failure because the machine simply cannot process data an arbitrarily high
rate and errors are returned to the application and crashes or memory
corruption resulting from feeding too fast. In the first case, the
application should track and limit the number of pending IOOPs (through some
internal method) to avoid overrunning all hardware resources; in the second
case, your have a code bug (most likely in synchronization code) and it
needs to be found & fixed
wrote in message news:xxxxx@ntdev…
- can’t not LINK function “timeGetDevCaps” is fixed
Because I use WDK win7 x86 check build, it should include target libs into
the source file.
- TIMECAPS value get by timeGetDevCaps, on my PC, Min is 1 and MAX is
1,000,000
Which value is high resolution after using timeBeginPeriod? Min or Max?
If I want to delay time with value between 1ms to 10ms of function
Sleep(), what value should I set in the timeBeginPeriod?
- From Tim’s help text
If I did not known the original resolution of my PC timer, and what ever
it is.
Can I consider that: code “Sleep(5)”, could only be wait more than 5ms,
but no case of less than 5ms? For the reason of original scheduler
interval is more than 5ms and “ready but not running immediately” even
make the time more longer?
As far as I know, the time honored by Sleep can never be less than the
number of ms you request. But it is unbounded as far as maximum delay is
concerned.
Note that many, perhaps nearly all, kernel threads run at priorities >=
16. Unless you have the privileges to do otherwise, the threads in your
app all run at < 16. This means that if your driver is running in an
environment that needs a disproportionate amount of kernel thread
execution, you could be talking about delays two or three orders of
magnitude greater than your request. Also, look at the MultiMedia
Scheduling Service if you are running Vista+, which allows any app to get
thread priorities in a “normal” app to lie between 16 and 25 or 26, I
don’t have my course notes handy. This can work for you, allowing you to
get better-than-expected response time, or against you, because other apps
using MMSS (or some vaguely similar acronym) could interfere with your
app.
If your thread is marked “ready to run” it is placed at the tail of all
other threads of that priority, and will run after all higher-priority
threads have run and all the threads ahead of it have run (which
description naively ignored multicore scheduling effects).
- processor was a 90 MHz Pentium. At that rate, 15ms gets you about 1.5
million cycles.
Sorry, how you calculate the cycles?
I re-calculate it:
it should be: 1,350,000 cycles.
Which is about 1.5 million, depending on what you mean by “about”. Also,
CPU cycles are not a good measure of expected performance because all
architectures beyond and including the Pentium II have at least caches,
instruction pipes, and dynamic register renaming. In later architectures,
the notions of superscalar architectures with opportunistic execution,
hyperthreading, speculative reads, and branch prediction got added until
the modern chips resemble supercomputer mainframes of the 1980s. So
“cycles”, as such, do not allow direct cross-comparison of performance
across chip generations. Even the hoary old MIPS designations are no
longer good indicators. Then add in multicore performance bottlenecks
such as cache coherency management and (over)use of the LOCK prefix, and
you find that clock speed, memory speed, etc. are at best indicators of
performance, but the complexity of execution patterns does not let you say
“machine X will be this much faster than machine Y”. Then you end up, in
some cases, where refactoring a computation to be cache-aware can buy you
factors of 20-50, and making anything that does paging becoe refactored to
be paging-aware, and you can see improvements of 3 to 5 orders of
magnitude for disproportionately small coding effort. In recent years,
add offloading to GPUs, and the discussions have to end up at “wall clock
time”.
So don’t be overly fixated on precision of cycle computations.
- How can I measure the Sleep delay correctness?
After I call “timeBeginPeriod(1)”
Then
/////
QueryPerformanceFrequency(&nFreq);
dqFreq=(double)nFreq.QuadPart;
printf(“Freq: %d\n”, nFreq.QuadPart);
QueryPerformanceCounter(&time_start);
Sleep(5);
QueryPerformanceCounter(&time_over);
printf(“Time consuming:
%f\n”,(time_over.QuadPart-time_start.QuadPart)/dqFreq);
/////
the print result is:
Freq: 2435927
Time consuming 0.004306
Does this value is really express the Sleep(5) or not?
I under Tim’s text as:
As my app call Sleep(5). then my app relinguish its time slice, and after
5ms, it return and get the CPU, but in this idle time, tick is going on
so the QueryPerformanceCounter function is get the absolute time, so this
value is right?
Does my understand right?
Yes, but then note that on multicore machines, each has its own frequency
counter, and the core you are executing on when you ask to QPC to get the
end tie may not be the core you are executing on when you read the start
time, unless you SetThreadAffinity to only one core. And while this
renders the RDTSC time more correct, it also disallows opportunistic
thread execution on whatever core is available, which means that although
your timing may be more precise, the actual time-to-completion may be
artificially biased high because only one core is allowed to run the
thread.
I still think Sleep is the wrong approach here; I’d be looking at how to
modify the driver so that the offending IRP cannot be dispatched if there
is a conflict.
joe
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer