Please, make it once more clear the technical difference between these three things around MS Windows systems. First is Timer Resolution you may set and get via ntdll.dll non-exported functions NtSetTimerResolution and NtQueryTimerResolution or use the Sysinternals' clockres.exe tool.
One of the scandalous trick used by the Chrome browser some time ago to perform better across the web. (They left high resolution trick for Flash plugin only at the moment). https://bugs.chromium.org/p/chromium/issues/detail?id=153139
https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/
In fact Visual Studio and SQL Server in some cases do the trick as well. I personally feel like it performs the whole system better and crisp, not slow down as many people warn out there.
What is the difference between the timer resolution and application I/O and memory priority (realtime/high/above normal/normal/low/background/etc.) you may set via Task Manager except the fact that the timer resolution sets up for the whole system, not a single application?
What is the difference between them and Processor scheduling option you can adjust from CMD > SystemPropertiesPerformance.exe -> Advanced tab. By default, the users' OS versions (like XP/Vista/7/8/8.1/10) set the performance of programs, the servers' versions (2k3/2k8/2k12/2k16) do care of background services. How this option interacts with those two above?
timeBeginPeriod() is the documented api to do this. It is documented to affect the accuracy for Sleep(). Dave Cutler probably did not enjoy implementing it, but allowing Win 3.1 code to port made it necessary. The multi-media api back then was necessary to keep anemic hardware with small buffers going without stuttering.
Very crude, but there is no other good way to do it in the kernel. The normal state for a processor core is to be stopped on a HLT instruction. Consuming (almost) no power, the only way to revive it is with a hardware interrupt. Which is what it does, it cranks up the clock interrupt rate. Normally ticks 64 times per second, you can jack it up to 1000 with timeBeginPeriod, 2000 with the native api.
And yes, pretty bad for power consumption. The clock interrupt handler also activates the thread scheduler, an fairly unsubtle chunk of code. The reason why a Sleep() call can now wake up at (almost) the clock interrupt rate. Tinkered with in Win8.1 btw, the only thing I noticed about the changes is that it is not quite as responsive anymore and a 1 msec rate can cause up to 2 msec delays.
Chrome is indeed notorious for ab/using the heck out of it. I always assumed that it provided a competitive edge for a company that does big business in mobile operating systems and battery-powered devices. The guy that started this web site noticed something was wrong. The more responsible thing to do for a browser is to bump up the rate to 10 msec, necessary to get accurate GIF animation. Multi-media playback does not need it anymore.
This otherwise has no effect at all on scheduling priorities. One detail I did not check is if the thread quantum changes correspondingly (the number of ticks a thread may own a core before being evicted, 3 for a workstation). I suspect it does.
Related
I would like to adjust the CPU frequency , in other word, looking for an API or c++ code for frequency scaling in windows ?
In Windows, you can call SetPriorityClass to set the priority of the process
You can also set the priority of a thread by calling SetThreadPriority
The CPU clock speed is not something for which there are just some simple instructions to execute. The clock speed is controlled by the motherboard chipset, and that in turn is controlled by a motherboard-specific device driver.
You can get some control over the clock speed by using the Windows settings for power management. The usual way to slow things down and save energy is to choose a setting on this basis. Modern laptop, tablet and phone computers have extremely sophisticated algorithms but you can hint them in the direction of less power.
You may be able to automate the operation of these Windows programs, if that's all you need.
Many motherboards come with the ability to overclock, and a utility to control it. If you have such a motherboard you may be able to find a way to automate its control program, or it may provide an API. It will not be a generic solution, but one highly specific to the motherboard. Check with your motherboard supplier.
Is there a general Windows capability to do this? Not so far as I know, but there could be something hiding in there somewhere. It will be privileged call to a device driver requiring admin rights, if it exists. My be is that it doesn't.
You can use: PowerWriteDCValueIndex(); / PowerWriteACValueIndex(); with PowerSetActiveScheme(NULL, pwrGUID);
I'm trying to test my project in high priority because the wall-clock timing I have in code seemed to be too long. I have already tried setting my .exe to run in high priority through the command line. It brought back the same time. Someone suggested that I use visual studio's #pragma to make it high priority, however I cannot find how to do that.
Note, my current project is single thread.
Is there any other way?
specific project is: timing sound initialization of soundcard (digital->analog) and DAQ (analog->digital). It's taking 1.1013 to 0.998 seconds, and I'm going to need it to be more precise because I'm using the DAQ to acquire data of a process that only takes around 10ms
If a certain function in your software requires to run in high priority, use the Windows functions SetThreadPriority or SetPriorityClass.
As soon as running at high priority is not required anymore, your software should revert back to normal priority. Do not try to keep your application running always and generally as "high priority". This would be hostile behavior :)
More information at:
msdn.microsoft.com/en-us/library/windows/desktop/ms685100.aspx
I'm developing an application in LabView on Windows. Starting a week ago, one test machine (a ToughBook, no less) was freezing up completely once every couple days: no mouse cursor, taskbar clock frozen. So yesterday it was retired. But just now, I've seen it on another machine, also a laptop.
This is a pretty uncommon failure mode for PC's. I don't know much about Windows, but I'd expect it to indicate that the software stopped running so completely and suddenly that the kernel was unable to panic.
Is this an accurate assessment? Where do I begin to debug this problem? What controls the cursor in the Windows architecture — is it all kernel mode or is there a window server that might be getting choked by something? Would an unstable third-party hardware driver cause this, rather than a blue screen?
EDIT: I should add that the freezes don't necessarily happen while the code is running.
I'd certainly consider hardware and/or drivers as a possibility - perhaps you could say what hardware is involved?
You could test this by adding a 'debug mode' for each piece of hardware your LabVIEW code talks to, where you would use e.g. a case structure to skip the actual I/O calls and return dummy data to the rest of the application. Make sure it's a similar amount of data to what the real device returns. You'll find this much easier if you've modularised your code into subVI's with clearly defined functions! If disabling I/O calls to a particular bit of hardware stops the freezes it would suggest the problem might be with that hardware or its driver.
Hard to say what the problem is. Base on the symptoms I would check for a possible memory leak (see if your LabVIEW app memory usage is growing overtime using "windows task manager").
recently this post inspired me, I want to track my own life, too.
I take a look at my cellphone's clock every time when go to sleep or after wake up, so I need some program to hook to my cellphone's on/off button, and log the timestamp when I press it.
I am using WM6.5 on a HTC TyTN II. If there is existing software that can do this with few settings and tweaks it would be nice, but I can also write code myself. Any suggestions?
You can use the device power notifications by P/Invoking RequestPowerNotifications to know when a power state changes (there's a CodeProject article that covers this as well). Be aware that the power down notification doesn't wait for subscribers to run code, so in most cases your application's handler doesn't actually run until the device wakes back up (meaning that if you're writing a timestamp or something you're going to get the wake time, not the sleep time).
Also be aware that different devices handle power management differently, so YMMV.
This is more tricky than you could possibly imagine!
The 'on/off' button isn't directly available to the OS (i.e. it's not visible in the keypad driver), as it is hooked into a rather complex system of power collapse (basically, the Apps CPU is completely powered down when the phone is 'off' - the modem wakes up according to the network-configured paging cycle).
The wake-sleep interactions of the two CPUs are extremely complex, and prone to race conditions. Even if you managed to hook it (which would require deep kernel-level programming and a number of security hacks), you would probably make your phone very unstable.
I am doing some performance measurement of my code on a Windows box and I am finding that I am getting dramatically different results between measurements. A quick bit of ad hoc exploration during a slow one shows in the task manager System Idle Processes taking up almost 100% CPU.
Does anyone know what System Idle Processes actually means and what Windows features it may be running?
NB: I am not measuring performance using the task manager, I just used it to take a look at what else was running during a particularly slow measurement.
Please think before saying this is not programming related and closing the question. I would not ask it unless I thought there were grounds to say it is. In this case I believe it clearly is because it is detrimentally affecting my development and test environments and in order to sort it out I need to know a bit more about it. Programming does not start and end with the writing of the code.
The idle process typically doesn't do any useful work except execute the HLT instruction, which puts that CPU core into a lower power state (C1). However, the fact that your benchmark is not consuming 100% CPU time does open the door for speculation about what is going on.
If your application is single-threaded and your test system is multicore/hyperthreaded/multi-CPU, then you should expect to see around 50% idle CPU time for two cores, 75% for four, etc. This is because the CPU time percentages in Task Manager include all cores. (I believe that older versions of Windows had an option to change this, but I don't see it on Vista.)
If the idle process is consuming a lot of CPU, that may indicate that your application is spending a lot of time sleeping. It might be waiting for data from some external source (e.g. a disk or network). It might be spending a lot of time waiting for synchronization objects (e.g. mutexes or events). It also might be spending a lot of time calling the Sleep() function. Profiling your code should identify where it's spending the time.
Getting fully reproducible benchmark results may require you to disable processor/disk/network-intensive background applications and services (e.g. search indexing, SMS software inventory, virus scanning, Windows Update downloads, IncrediBuild/distcc) or to connect the machine to an isolated network (or to no network at all).
I'm assuming that you wrote a benchmark for your application, and that you're just trying to use Task Manager to diagnose why the benchmark results aren't what you expected. Task Manager isn't an accurate way to measure application performance.
System Idle Process is a sort of a default process that Windows runs on the processor when it has nothing else to schedule for running. This process is like a housekeeper that does things like trying to save system power etc.
If you're measuring the performance of your program, don't use the Windows Task manager. Use Performance Monitor instead (which you can start by typing 'perfmon' at the commandline). Or better still, use a profiler.
If you "system idle process" is taking up 100% then essentially you machine is bored, nothing is going on. If you add up everything going on in task manager, subtract this number from 100%, then you will have the value of "system idle process." Notice it consumes almost no memory at all and cannot be affecting performance.