I'm trying to disable CPU Core Parking feature on window 10 so that my multi-processing code can utilize the full capacity of my processor (here is a question I asked earlier for context). I tried every solution mentioned here to disable this feature (and many more) and nothing seems to be working, no matter what I do, this annoying Parked tag keeps showing up in the resource monitor.
the confusing part is that; according to the approach of manually editing registry entries, the max value of the key:
0cc5b647-c1df-4637-891a-dec35c318583
should be changed from 100% to 0%, while using a 3rd party application such as Park Control or Quick CPU sets the max value of the same registry key to 100% and surprisingly, neither is working.
I appreciate any help and thanks in advance.
Related
My dev machine is absolutely crawling - programs frequently non-responsive, etc. It turns out VS2019 is maxing out my CPU (80-100%) for minutes at a time even when I'm not using it, and I've identified "Background Tasks" as the culprit, namely Intellisense. This is not simply when loading a solution, but hours later.
Is it possible to control how much CPU resource it is allowed to use? I don't want to turn it off (not sure if it's possible) but are there any settings because it is making my machine almost unusable.
I have been investigating the windows Prefetching system hoping to find a way to speed up the load time of an application I am working on. I found the following link where a developer describes modifications to the prefetcher registry values:
http://dotnet.dzone.com/news/improving-cold-startup
I have made similar modifications locally and found that they do provide faster application loading times. My problem is that I cannot find any documentation on the registry values that were changed and why the new values are better than the old ones.
So my question in short is, does anybody have any further information on the prefetcher registry values given below:
VideoInitTime
EnablePrefetcher
AppLaunchMaxNumPages
AppLaunchMaxNumSections
AppLaunchTimerPeriod
BootMaxNumPages
BootMaxNumSections
BootTimerPeriod
MaxNumActiveTraces
MaxNumSavedTraces
RootDirPath
HostingAppList
You don't say what profiling or other changes you've done, and when people dive in with off-the-wall solutions to perf problems but don't describe how they arrived at the need for them, I'm always a bit doubtful.
Where is your app spending its start-up time? How did you measure that? Can you fix an underlying '300 dlls' problem of the type described in that article?
Messing with OS prefetch policy may being improving your application at the expense of everyone else, which may be the right thing to do (on a single-use industrial control system or something like that), but may be completely antisocial.
"Load less code" is often a good general way to improve application startup time - do you have some very expensive config file storage mechanism, for example (XmlSerializer was notorious for this at one point, for example).
I have a WinForms application that uses XNA to animate 3D models in a control. The app have been doing just fine for months but recently I've started to experience periodic pauses in the animation. Setting out to investigate what is going on I have established these facts:
It happens on my machine only, other machines works fine
Removing everything from my render loop does not improve the problem
In 2. I didn't actually remove everything, I limited my loop to set the viewport on my GraphicsDevice and then do a GraphicsDevice.Present.
Trying to dig further I fired up PIX to capture some statistics. Screenshots of two PIX runs can be viewed here (Run6) and here (Run14). Run6 is using my original render loop and Run14 is using the bare-bones Present loop.
PIX tells me that the GPU is periodically doing something, and I assume this is causing the pauses. What could be the cause of this? Or how do I go about finding out what the GPU is actually doing?
Update: since I usually trust my code to be perfect (who's laughing?) I started a new XNA project from scratch to see if it exhibit the same behavior. So starting a new XNA 3.1 Windows Game project and running PIX I get this timeline. The same periodic pauses. So the problem must be lower in the stack, in XNA or Direct3D.
So PIX shows that the GPU is working on something, I can see the list of DX calls made within each frame and the timing calculations shows that the pause occurs during (or after) the IDirect3DDevice9::Present call.
Update 2: I had previously installed and uninstalled XNA 4.0 CTP on the problematic machine. I cannot be certain that this is related but I thought that perhaps a reinstall of the XNA Game Studio 3.1 bits could make a difference. Turns out it did.
The underlying question remains the same (and the bounty is still up): what could affect XNA 3.1 (or DirectX) to make it behave like this and is there any logging/tracing power tool for the DirectX and/or GPU level out there that could shed some light on what is going on?
Note: I'm using XNA 3.1 on a Windows 7 x64 dual-core machine with 8GB RAM.
Note2: also posted this question on the XNA Creators forums here.
You could try to see if you can find something with Xperf that is close to your periodically problem, do not run your application but keep the programs open that would normally run besides your application. You could also try to do it again with the application running but it could give a cluttered view.
Start the tracing, do this in an elevated prompt.
xperf -on BASE+LATENCY -stackWalk Profile
Wait for a fair amount of time to be sure that the problem is traced.
Stop the tracing and open it like this.
xperf -d trace.etl
xperfview trace.etl
Analyze by looking at the graphs and consulting tables of specific intervals and see if you can find something that is related to the problem, the highest chance on finding it would be in the DPC and Interrupts section. But it might as well be something odd at the CPU or I/O section. Good luck!
Also more information on Xperf and how to obtain it, hopefully this delivers results.
If not, you can alternatively try GPUView which has been used for improvements in DWM,
this is also included next to Xperf with the Windows Performance Toolkit so you can easily try both!
log v
... wait for a fair amount of time to be sure that the problem is traced ...
log
gpuview merged.etl
In the case that gpuview gets out of memory you can try to add "/limit 3" or remove the v.
Read the documentation of the tools if you are stuck somewhere.
Hmm ... this seems to be occurring on the GPU, however it sounds like a CPU garbage collection issue. Can you run the CLR profiler and see if you can see any spikes in GC activity that you can correlate to the slowdowns?
I agree that it sounds unlikely since you can clearly see it in PIX, but it might offer a clue as to the cause.
If it's only happening on your own machine, then could it be drivers? Forgive me for being skeptical, but it's a 64 bit machine after all :D
This looks like either a vsync issue or GPU in its last throes. Since going back to a different version fixed it, and the "bottleneck" is in IDirect3DDevice9::Present lets go with the former option.
I'm not familiar with XNA so I don't know how much of the workings of D3D are exposed, but do you know what your PresentationParameters are set to?
Specifically try setting the swap effect set to Discard.
How do I reversably slow a PC with XP?
I want to achieve this without using visible CPU-cycles, so I'm guessing some hardware settings might do.
I don't want my app to run slow, I want the whole OS to be slow. I know some network lookups especially out of a trusted environment (think Active Directory) slow a PC way down. This is the effect I want.
Disclaimer: this is not for a bad/evil/illegal cause!
We use a 'crippled' server we call doofus for load testing. it is an old P3/500 box with limited RAM.
Another option is setting up a VM with very limited resources.
Use powercfg.exe, to force the computer to a power plan you've created that locks the CPU into a lower frequency to conserve power. What states are available depend on your platform (most desktops only have a couple.)
If you think your hardware setup can handle it, some motherboards let you manually specify a clockspeed multiplier or other speed settings in the BIOS. Often there'll be an option for a slower speed or a field where you can manually enter a lower multiplier.
If not, you might consider setting up a virtual machine, and making sure it's not fully virtualized - paravirtualized machines run slower due to the necessary translations that take place in the virtualization layer.
The open source Bochs emulator is pretty easy to slow down by editing its config file. Windows XP will run in it. It is not as powerful as vmware, but there are many more configuration options.
Look at the documentation for the config file, "bochsrc", and particularly the "IPS" entry. (Instructions Per Second)
Remove the thermopaste and put some dust on the CPU :-) Also, remove some RAM.
You may want to take a look at a full-system simulator such as Simics. Simics allows you deterministically simulate an entire system (including networks, if you want). Not only can you tweak the CPU frequency, you can study the system in detail to see how it behaves.
Unfortunately, Simics has quite a pricetag.
If you want to see really dramatic effects very easily, set the /MAXMEM switch in boot.ini (or use msconfig). This will limit the amount of memory used by the system - switching to 256mb or lower would make things very, very slow.
You have lots of options. Things I can think of:
Change your disks to good old fashioned IDE. None of that high-speed DMA stuff, just good old fashioned PIO.
Remove RAM (or diable in the BIOS)
Switch to generic video drivers (I mean "Generic SVGA" type, that are un-accelerated)
Disable core(s) in the BIOS
Slow the CPU down in the bios (if possible)
We keep an old laptop around for this reason. Helped me to find a subtle timing issue in some splash screen code that was absolutely unreproducable on decent quad core dev boxes.
Install Norton 360. It makes the mouse cursor lag during updates and constantly nags for restarts.
Disable the L2 cache in the BIOS
Two Windows applications: Mo'Slo and Cpukiller.
I remember hearing of one that grabs large chunks of RAM, to reduce your available RAM, but I forget what it is called.
I'm working on a small free Cocoa app that involves some SFTP functionality, specifically working with uploads. The app is nearing completion however I've run into a pretty bad issue with regards to uploading folders that contain a lot of files.
I'm using ConnectionKit to handle the uploads:
CKTransferRecord * record;
record = [connection recursivelyUpload:#"/Users/me/large-folder"
to:#"/remote/directory"];
This works fine for most files and folders. Although in this case #"/Users/me/large-folder" has over 300 files in it. Calling this method spins my CPU up to 100% for about 30 seconds and my application is unresponsive (mac spinning ball). After the 30 seconds my upload is queued and works fine, but this is hardly ideal. Obviously whatever is enumerating these files is causing my app to lock up until it's done.
Not really sure what to do about this. I'm open to just about any solution - even using a different framework, although I've done my research and ConnectionKit seems to be the best of what's out there.
Any ideas?
Use Shark. Start sampling, start downloading, and as soon as the hang ends, stop sampling.
If the output confirms that the problem is in ConnectionKit, you have two choices:
Switch to something else.
Contribute a patch that makes it not hang.
The beauty of open-source is that #2 is possible. It's what I recommend. Then, not only will you have a fast ConnectionKit, but once the maintainers accept your patch, everyone else who uses CK can have one too.
And if Shark reveals that the problem is not in ConnectionKit (rule #2 of profiling: you will be surprised), then you have Shark's guidance on how to fix your app.
Since the problem is almost certainly on the enumeration, you'll likely need to move the enumeration into an asynchronous action. Most likely they're using NSFileManager -enumeratorAtPath: for this. If that's the main problem, then the best solution is likely to move that work onto its own thread. Given the very long time involved, I suspect they're actually reading the files during enumeration. The solution to that is to read the files lazily, right before uploading.
Peter is correct that Shark is helpful, but after being a long-time Shark fan, I've found that Instruments tends to give more useable answers more quickly. You can more easily add a disk I/O and memory allocation track to your CPU Sampler using Instruments.
If you're blocking just one core at 100%, I recommend setting Active Thread to "Main Thread" and setting Sample Perspective to "All Sample Counts." If you're blocking all your cores at 100%, I recommend setting Active Thread to "All Threads" and Sample Perspective to "Running Sample Times."