So, my brother was playing Fortnite and it was lagging quite a bit. So I offered to make an application that will limit the CPU usage of other apps, but I actually am having trouble with getting the limit to go on the other application.
Here's the code I've tried:
public void ThrottledLoop(Action action, int cpuPercentageLimit)
{
Stopwatch stopwatch = new Stopwatch();
while (true)
{
stopwatch.Reset();
stopwatch.Start();
long actionStart = stopwatch.ElapsedTicks;
action.Invoke();
long actionEnd = stopwatch.ElapsedTicks;
long actionDuration = actionEnd - actionStart;
long relativeWaitTime = (int)(
(1 / (double)cpuPercentageLimit) * actionDuration);
Thread.Sleep((int)((relativeWaitTime / (double)Stopwatch.Frequency) * 1000));
}
}
Please help, if there is any other information you need just let me know.
Thanks
Summary from comments above.
You can specify what processors ("affinity") processes are allowed to run on. This offers more fine grain control than setting process priority.
e.g. limit certain processes to say the last 4 cores on a system with 16 logical cores but allowing Fortnite to use whatever it wants. Be aware, some apps might not take too kindly to it.
Anti-virus programs sometimes play nice by keeping themselves at the end of the list of cores in a system.
For an example take a look at the Windows Task Manager Details tab.
See also
How can I set processor affinity to a thread or a Task in .NET?
I'm trying to make a sort of task manager -esque program using PerformanceMonitor and a chart. The CPU usage value is thrown onto a label and the chart, obviously, graphs it all out.
Problem is PerformanceMonitor only reports the CPU being at nothing or full, but the graph shows lots of little spikes in between, usually not matching the Windows Task Manager graph output.
I need to know how I can get PerformanceMonitor, or a similar C# product, to output viable, consistent, and accurate information into the graphing chart.
Code below. Timer interval is set to 25 for testing purposes currently.
public partial class formMain : Form
{
int usage;
int x = 1;
protected PerformanceCounter countCpu;
public formMain()
{
InitializeComponent();
myInit();
}
private void myInit()
{
countCpu = new PerformanceCounter("Processor", "% Processor Time", "_Total");
timerMain.Tick += new EventHandler(timerMain_Tick);
timerMain.Start();
}
private void timerMain_Tick(object sender, EventArgs e)
{
usage = Convert.ToInt32(countCpu.NextValue());
chartCpu.Series["CPU"].Points.AddXY(x, usage);
lblCpu.Text = Convert.ToString(usage.ToString()) + "%";
x++;
if(chartCpu.ChartAreas[0].AxisX.Maximum > chartCpu.ChartAreas[0].AxisX.ScaleView.Size)
{
chartCpu.ChartAreas[0].AxisX.ScaleView.Scroll(chartCpu.ChartAreas[0].AxisX.Maximum);
}
}
}
Here's a screenshot detailing what I mean.
Your spiky graph is a standard mishap when you use that PerformanceCounter. A processor only has two states, running full bore as fast as it can or turned off completely when no work needs to be done. The perf counter tells you how often it was running vs how often it was turned off since you last called the NextValue() method.
If you do that too fast then the resolution suffers, you get too many samples that are 0, 33, 50, 67 or 100. Make it really short and you'll only ever get 0 or 100. So the primary diagnostic here is that your Timer.Interval is too short. You probably left it at the default, 100 msec. You need to make it 1000 to emulate the behavior of Task Manager or Performance Monitor.
Furthermore, on modern version of Windows you need to use a different PerformanceCounter to emulate what you get from the Windows utilities. That counter lives in the "Processor Information" category, still called "% Processor Time". It is a tweaked counter that better represents the amount of work a modern processor really does. Which is convoluted, modern processors dynamically adjust their clock frequency based on the chip temperature, so the amount of work they do is affected by what they've done before. And they emulate an extra core with hyper-threading. That extra logical core however cannot do as much work as a real core. The tweaked counter tries to compensate for these effects.
It is because of your timer interval. Procesors don't have such a thing like CPU usage, they have CPU time (how much CPU spent time being active), so let's say your CPU time was 200 in now and will be 400 after a second, so (400 - 200) ms / 1000 ms * 100% equals 20 % CPU usage. Now lets say you need to calculate your CPU usage each 1 ms. Because CPU time is only integer, after that 1 ms you are trying to calculate, your CPU time will likely increase in 1 or even not increase at all. So (201 - 200) ms / 1 ms * 100% equals 100 %. The higher your interval is, the more accuracy you'll get in CPU usage calculation.
Managed to accidentally fix this by removing the myInit method and adjusting the code.
Final code:
public partial class formMain : Form
{
int usage;
int x = 1;
protected PerformanceCounter countCpu = new PerformanceCounter("Processor", "% Processor Time", "_Total");
public formMain()
{
InitializeComponent();
timerMain.Tick += new EventHandler(timerMain_Tick);
timerMain.Start();
}
private void timerMain_Tick(object sender, EventArgs e)
{
usage = Convert.ToInt32(countCpu.NextValue());
chartCpu.Series["CPU"].Points.AddXY(x, usage);
lblCpu.Text = Convert.ToString(usage.ToString()) + "%";
x++;
if(chartCpu.ChartAreas[0].AxisX.Maximum > chartCpu.ChartAreas[0].AxisX.ScaleView.Size)
{
chartCpu.ChartAreas[0].AxisX.ScaleView.Scroll(chartCpu.ChartAreas[0].AxisX.Maximum);
}
}
}
I've got the following code that is supposed to measure the current download and upload speed. The issue I'm facing is that there are often usages recorded that my network and/or internet connection can't even handle (above my bandwidth).
public static IStatistics GetNetworkStatistics(string interfaceName) {
var networkStats = _interfaces[interfaceName];
var dataSentCounter = new PerformanceCounter("Network Interface", "Bytes Sent/sec", interfaceName);
var dataReceivedCounter = new PerformanceCounter("Network Interface", "Bytes Received/sec", interfaceName);
float sentSum = 0;
float receiveSum = 0;
var sw = new Stopwatch();
sw.Start();
while (sw.ElapsedMilliseconds < 1000) {
sentSum += dataSentCounter.NextValue();
receiveSum += dataReceivedCounter.NextValue();
}
sw.Stop();
Console.WriteLine("Download:\t{0} KBytes/s", receiveSum / 1024);
Console.WriteLine("Upload:\t\t{0} KBytes/s\n", sentSum / 1024);
networkStats.AddSentData(sentSum);
networkStats.AddReceivedData(receiveSum);
return networkStats;
}
Sample output:
As you can see most of these entries indicate a pretty heavily used network, up to an excessive amount of almost 160MB/s. I realize that you can't measure transfer speed with just one record (this is test data, in the actual application I use the mean of the latest 3), but even so: how can I ever receive 160MB in one second. I believe it's safe to say that I must have made an error somewhere, but I can't find where.
One thought I had was that I should keep a counter in the loop to show me how many times the PerformanceCounter.NextValue() were accessed (generally between 46 and 48), but in the end I believed this shouldn't matter: in the grand picture I'm still having a too large number for just one second of bandwidth usage. I can't shake the feeling that the performance counter might be the cause though.
Sidenote: the 160MB/s number was recorded the moment I loaded a new youtube video and other (+1000 KB/s) recordings are usually done when I refresh a tab, so it should be a (relative) display of my network usage.
Have I overlooked something in my approach?
Edit:
Upon following #Sam's advice and checking my results against the built-in perfmon.exe I noticed that my bursts in bandwith usage generally occur at the same time as those shown in Perfmon, but mine are way larger. I have tried to link the simultaneous bursts and find something in common, but it seems rather random (possibly because Perfmon might combine several results to get their current speed, whereas I'm only using the latest second).
Same goes for the lower numbers: Perfmon usually shows < 10kbps whereas I'm constantly around 50kbps.
Edit2:
This is the code I used in reference to #Hans' comment
var initSent = dataSentCounter.NextValue();
var initReceived = dataReceivedCounter.NextValue();
Thread.Sleep(1000);
sentSum = dataSentCounter.NextValue() - initSent;
receiveSum = dataReceivedCounter.NextValue() - initReceived;
My first post here, but this site has answered many questions that I have had in the past. Hopefully I can give enough detail to explain the issue I am facing as I don't fully understand how all .NET is handling the threads I create!
OK so basically, I have a thread set to run every 1000ms which gets a frame counter from a video encoder and calculate the FPS. Accuracy is sufficient with a System.Threading.Timer for now though I realise it isn't accurate (often over 1000ms between events). I also have another Threading.Timer which is running and taking a reading from a network to serial device. The issue is that if the network device becomes unavailable and the socket timesout on that timer the FPS timers go completely out of sync! So they were previously executing every 1015ms (measured) but when I start this other Thread.Timer trying to make a socket connection and it fails it causes the FPS counter timers to go totally off (up to 7000ms!!). Am not quite sure why this should be and really need the FPS counter to run once a second pretty much no matter what.
Bit of code ->
FPS Counter
private void getFPS(Object stateInfo)//Run once per second
{
int frames = AxisMediaControl.getFrames; //Axis Encoder media control
int fps = frames - prevValue;
prevValue = frames;
setFPSBar(fps, fps_color); //Delegate to update progress bar for FPS
}
Battery Level Timer
while (isRunning)
{
if (!comm.Connected) //comm is standard socket client
comm.Connect(this.ip_address, this.port); //Timeout here causes other timer threads to go out of sync
if (comm.Connected)
{
decimal reading = comm.getBatt_Level();
//Calculate Readings and update GUI
Console.Out.WriteLine("Reading = " + (int)prog);
break;//Debug
}
This is the code used to connect to the socket currently ->
public Socket mSocket { get; set; }
public bool Connect(IPAddress ip_address, UInt16 port)
{
try
{
mSocket.Connect(ip_address, port);
}
catch(Exception ex)
{
}
return mSocket.Connected;
}
Hopefully not too ambiguous!
While I don't know why your FPS timer is not called for 7s, I can suggest a workaround: Measure the TimeSpan since the last time the FPS value was updated by remembering the Environment.TickCount value. Then, calculate the FPS value as (delta_frames / delta_t).
Thanks for the comments, I fixed it by doing the following.
Used a System.Timers.Timer instead and set auto-reset to false. Each time one of the timers completes I start it again, this means there is only ever one timer for each battery device. The problem with the initial solution is that the network timeout was causing the threads to stay alive for much longer than the timer interval. Thus, to ensure the timer interval was met a new thread was spawned more frequently.
During runtime this meant there was about 5-7 threads for each battery timer (whereby 6 are timing out and 1 is about to begin). Changing to the new timer means there is only one thread now as it should be.
I also added in the code to calculate the FPS based on the time taken (using Stopwatch function for higher accuracy (thanks USR)). Thanks for the help. I will have to make sure not to just leave exceptions blank too.
Of late, I'm becoming more health oriented when constructing my program, I have observed that most of programs take 2 or 3 minutes to execute and when I check on the task scheduler, I see that they consume 100% of CPU usage, can I limit this usage programatically in code? This will certainly enable me to run multiple programs at a given time.
Thanks,
Nidhi
This thread is over four years old, and it still annoys me that the accepted answer criticizes the question rather than answering it. There are many valid reasons you would want to limit the CPU time taken by your program, I can list a few off the top of my head.
It might seem like a waste not to use all free CPU cycles available, but this mentality is flawed. Unlike older CPUs, most modern CPUs do not run at a fixed clock speed - many have power saving modes where they drop the clock speed and cpu voltage when load is low. CPUs also consume more power when performing calculations than they do running NOOPs. This is especially relevant to laptops that require fans to cool the CPU when it is under high load. Running a task at 100% for a short time can use far more energy than running a task at 25% for four times as long.
Imagine you are writing a background task that is designed to index files periodically in the background. Should the indexing task use as much of the CPU as it can at a lower priority, or throttle itself to 25% and take as long as it needs? Well, if it were to consume 100% of the CPU on a laptop, the CPU would heat up, the fans would kick in, and the battery would drain fairly quickly, and the user would get annoyed. If the indexing service throttled itself, the laptop may be able to run with completely passive cooling at a very low cpu clock speed and voltage.
Incidentally, the Windows Indexing Service now throttles itself in newer versions of Windows, which it never did in older versions. For an example of a service that still doesn't throttle itself and frequently annoys people, see Windows Installer Module.
An example of how to throttle part of your application internally in C#:
public void ThrottledLoop(Action action, int cpuPercentageLimit) {
Stopwatch stopwatch = new Stopwatch();
while(true) {
stopwatch.Reset();
stopwatch.Start();
long actionStart = stopwatch.ElapsedTicks;
action.Invoke();
long actionEnd = stopwatch.ElapsedTicks;
long actionDuration = actionEnd - actionStart;
long relativeWaitTime = (int)(
(1/(double)cpuPercentageLimit) * actionDuration);
Thread.Sleep((int)((relativeWaitTime / (double)Stopwatch.Frequency) * 1000));
}
}
First of all, I agree with Ryan that the question is perfectly valid and there are cases where thread priorities are not at all sufficient. The other answers appear highly theoretical and of no practical use in situations where the application is properly designed but still needs to be throttled. Ryan offers a simple solution for cases in which a relatively short task is performed in high frequency. There are cases, however, when the task takes a very long time (say a minute or so) and you cannot or don't want to break it into smaller chunks between which you can do the throttling. For these cases the following solution might be helpful:
Rather that implementing throttling into the business code, you can design the algorithm itself to work at full steam and simply throttle the thread which runs the operation "from the outside". The general approach is the same as in Ryan's answer: Calculate a suspension time based on the current usage and suspend the thread for this timespan before resuming it again. Given a process which you want to throttle, this is the logic:
public static class ProcessManager
{
[Flags]
public enum ThreadAccess : int
{
TERMINATE = (0x0001),
SUSPEND_RESUME = (0x0002),
GET_CONTEXT = (0x0008),
SET_CONTEXT = (0x0010),
SET_INFORMATION = (0x0020),
QUERY_INFORMATION = (0x0040),
SET_THREAD_TOKEN = (0x0080),
IMPERSONATE = (0x0100),
DIRECT_IMPERSONATION = (0x0200)
}
[DllImport("kernel32.dll")]
static extern IntPtr OpenThread(ThreadAccess dwDesiredAccess, bool bInheritHandle, uint dwThreadId);
[DllImport("kernel32.dll")]
static extern uint SuspendThread(IntPtr hThread);
[DllImport("kernel32.dll")]
static extern int ResumeThread(IntPtr hThread);
[DllImport("kernel32.dll")]
static extern int CloseHandle(IntPtr hThread);
public static void ThrottleProcess(int processId, double limit)
{
var process = Process.GetProcessById(processId);
var processName = process.ProcessName;
var p = new PerformanceCounter("Process", "% Processor Time", processName);
while (true)
{
var interval = 100;
Thread.Sleep(interval);
var currentUsage = p.NextValue() / Environment.ProcessorCount;
if (currentUsage < limit) continue;
var suspensionTime = (currentUsage-limit) / currentUsage * interval;
SuspendProcess(processId);
Thread.Sleep((int)suspensionTime);
ResumeProcess(processId);
}
}
private static void SuspendProcess(int pid)
{
var process = Process.GetProcessById(pid);
if (process.ProcessName == string.Empty)
return;
foreach (ProcessThread pT in process.Threads)
{
IntPtr pOpenThread = OpenThread(ThreadAccess.SUSPEND_RESUME, false, (uint)pT.Id);
if (pOpenThread == IntPtr.Zero)
{
continue;
}
SuspendThread(pOpenThread);
CloseHandle(pOpenThread);
}
}
private static void ResumeProcess(int pid)
{
var process = Process.GetProcessById(pid);
if (process.ProcessName == string.Empty)
return;
foreach (ProcessThread pT in process.Threads)
{
IntPtr pOpenThread = OpenThread(ThreadAccess.SUSPEND_RESUME, false, (uint)pT.Id);
if (pOpenThread == IntPtr.Zero)
{
continue;
}
var suspendCount = 0;
do
{
suspendCount = ResumeThread(pOpenThread);
} while (suspendCount > 0);
CloseHandle(pOpenThread);
}
}
}
The benefit of this solution is that the checking interval becomes independent of the duration of your "long running task". Furthermore, business logic and throttling logic are separated. The suspense/resume code is inspired by this thread. Please note that disposal and ending the throttling needs to be implemented in the solution above, it is not production code.
That's not your concern... It's the job of the operating system to distribute processor time between running processes. If you'd like to give other processes first crack at getting their stuff done, then simply reduce the priority of your own process by modifying the Process.PriorityClass value for it.
See also: Windows Equivalent of ‘nice’
You could write a Governor class that throttles the CPU usage. This class would contain a utility method that should be called on a regular basis (e.g. calling this utility function within a while loop of your function) by your CPU bound function. The governor would check if the amount of time elapsed exceeded a particular threshold, and then sleep for a period of time so as to not consume all the CPU.
Here's a simple Java implementation off the top of my head (just so you get the idea) that will throttle the CPU usage to 50% if you have a single threaded CPU bound function.
public class Governor
{
long start_time;
public Governor()
{
this.start_time = System.currentTimeMillis();
}
public void throttle()
{
long time_elapsed = System.currentTimeMillis() - this.start_time;
if (time_elapsed > 100) //throttle whenever at least a 100 millis of work has been done
{
try { Thread.sleep(time_elapsed); } catch (InterruptedExceptione ie) {} //sleep the same amount of time
this.start_time = System.currentTimeMillis(); //reset after sleeping.
}
}
}
Your CPU bound function would instantiate a Governor, and then just call throttle on a regular basis within the function.
Thank all of you for answering. I've been working on this and the exe it runs for a few hours and want to share to help others. I wrote a class I'm going to set and forget in a WPF app that'll encrypt and push data to the cloud, but I couldn't ever have it ever interfere with the timing of the WPF app and what the WPF app needs in the way of resources, which I am also going to add a flag to disable when the WPF app is in it's highest resource consumption state. I've already highly threaded this WPF with the TPL. This solution has both the priority set of the process
myProcess.PriorityClass = ProcessPriorityClass.Idle;
and the CPU percentage limited.
then in my mainDisplay.xaml.cs I'll use
ProcessManagement.StartProcess(5);
in MainWindow()
And there is no window popping up when that exe is run
RedirectStandardOutput = true,
UseShellExecute = false,
CreateNoWindow = true
in the object initalizer
internal class ProcessManagement
{
private static int CpuPercentageLimit { get; set; }
public static void StartProcess(int cpuPercent)
{
CpuPercentageLimit = cpuPercent;
var stopwatch = new Stopwatch();
while (true)
{
stopwatch.Reset();
stopwatch.Start();
var actionStart = stopwatch.ElapsedTicks;
try
{
var myProcess = new Process
{
StartInfo =
{
FileName = #"D:\\Source\\ExeProgram\\ExeProgram\\bin\\Debug\\ExeProgram.exe",
RedirectStandardOutput = true,
UseShellExecute = false,
CreateNoWindow = true
}
};
myProcess.Start();
myProcess.PriorityClass = ProcessPriorityClass.Idle;
myProcess.Refresh();
myProcess.WaitForExit();
var actionEnd = stopwatch.ElapsedTicks;
var actionDuration = actionEnd - actionStart;
long relativeWaitTime = (int)((1 / (double)CpuPercentageLimit) * actionDuration);
var sleepTime = (int)((relativeWaitTime / (double)Stopwatch.Frequency) * 1000);
Thread.Sleep(sleepTime);
myProcess.Close();
}
catch (Exception e)
{
// ignored
}
}
}
}
In my application, there is ample time, like 24/7/365, to upload lots of data, including thousands of images, but the UI also needs to stay active when used and when the system runs, nothing else can be running.
If you have a multi core processor, you can set the Affinity on each process to only use which cores you want it to use. This is the closest method I know of. But it will only allow you to assign percentages that are a factor of 50% on a dual core, and 25% on a quad core.
You can run your program in a thread with a lower threadpriority, the rest is up to your operating system. Having a process eat up 100% of your CPU is not bad. My SETI is usually taking up all my remaining CPU time without bothering my other programs. It only gets a problem when your thread gets priority over more important programs.
According to MSDN, you can only set a thread priority, i.e.
var t1 = new Thread(() => doSomething());
t1.Priority = ThreadPriority.BelowNormal;
t1.Start();
where doSomething is the function you want to create a thead for. The priority can be one of the ThreadPriority enumeration members Lowest, BelowNormal, Normal, AboveNormal, Highest - for a description see the MSDN link above. Priority Normal is the default.
Note that CPU usage also depends on how many cores and logical processors your physical CPU has *) - and how the threads and processes are assigned to those cores (the assignment to a dedicated processor is called "processor affinity" - if you want to know more about that, see this StackOverflow question).
*) To find that out, open the task manager (via Ctrl+Alt+Delete - select "task manager"), go to Performance and select CPU there: Below the utilization graph you can see "Cores" and "Logical processors". A core is a physical unit built into the CPU, while a logical processor is just an abstraction, which means the more cores your CPU consists of, the faster it can process parallel tasks.
I honestly think rather than worry about trying to limit CPU utilization by your app, you should focus more of your energies on profiling the application to uncover and correct bottlenecks and inefficiencies that may exist.
If you code is running at all, it is at 100%
I suppose slipping in some sleeps might have an effect.
I have to wonder about that 2-3 minute figure. I've seen it too, and I suppose it's loading and initializing lots of stuff I probably don't really need.
This is something I have come across a lot of times with complex integrations (for example a daily update of products, stock and pricing on an ecomm system).
Writing the integrations as efficiently as possible is always good, using DB server power where you can instead for iterating objects in the code but at the end of the day these things WILL take up processor time and you may want to run them on a server that is doing other things too.
Sharing is caring ;-)
A good approach to avoid coding a Governor or Throttling mechanism is to use the power of a web server. Expose the integration as a "local API call" and run it in IIS (for instance). There you have multiple throttling options and affinity masks you can apply to the application pool. This can then be easily adjusted "on the fly" to give a good balance and monitor closely.
If there is no other task running, is it wrong for your app to use all the cpu capacity that is available? It is available, as in it's there and it is free to use. So use it!
If you somehow limit the cpu usage of your task, it will take longer to complete. But it will still take the same number of cpu cycles, so you gain nothing. You just slow down your application.
Don't do it. Don't even try it. There's no reason why you should.
I think what you need to do is to understand the performance problem in your application instead of trying to put a cap on the CPU usage.
You Can use Visual Studio Profiler to see why you application is taking 100% CPU for 2-3 minutes in the first place. This should reveal the hot spot in your app, and then you can be able to address this issue.
If you are asking in general regarding how to do resource throttling in windows, then you can look at the "Task" objects, Job objects allows you to set limits such as Working set, process priority...etc.
You can check out the Job objects documentation here
http://msdn.microsoft.com/en-ca/library/ms684161(VS.85).aspx
Hope this helps.
Thanks