my cpu is getting way to hot when running rybka (even on one processor). over 90 c. Rybka is being far to demanding. I think there will need to be a fix where you can get rybka to use a bit less processing resources.
is 90 even in the relm of possibility with a latitude d620 core duo 2.16. It sounds like the thing is going to explode
This is a computer with no overclocking and default settings. I am going to have to try to undervolt it (see link above), or risk the whole darn think melting
By the way all chess engines use 100% CPU power ... or close to it. This post must be particulary funny to Vas because I had been complaining that Rybka was not utilizing 100% CPU as much as Fritz or Zappa ... I had noticed that Zappa and Fritz heat up the processors more than Rybka and thus that some cycles must be missing by Rybka and maybe more performance could be gained. According to Vas that is because Fritz and Zappa have optimizations at the machine level language and that it would not be worth the effort to gain the extra few cycles.
I never had this problem before, running rybka on both cores, for very long periods of time, so I am guessing vas has made the engine more able to use the processing resources.
In the Rybka 2.3.2a series, in the "Engine Parameters" window (smack in the middle-top right under "Max CPUs") is a window to adjust CPU usage from 0-100%. It's called "CPU Usage."
I found this unique feature extremely useful. In those instances where I wanted all resources directed to the chess engine so it could provide the best results fastest, it was always set to 100%.
However, what happens when this is set to 100% and I want to do something else while Rybka is working? Like check my email, write checks or do some internet browsing? Well there are frequent and annoying pauses to my system that makes performing these other tasks tedious. In my case, I found that by notching the CPU back to 95% I was able to do these other things smooth as silk - for non-competitive Rybka tasks, this was wonderful - the only impact is that Rybka takes slightly more time for an analysis, and not much, and I have enough use of my computer to be productive doing other things.
The "CPU Usage" was to me a wonderful feature and I miss it in Rybka3.
For remote computer engine COMPETITION, set it to 100%.
To do OTHER things during analysis work, 95% works absolute wonders. It was amazing to me how much difference 5% could make with respect to doing OTHER little tasks.
So I'd make a case for re-instating the 2.3.2a "CPU Usage" feature in Rybka3. I think that was the ONLY version to use it, and I'm very sorry now I didn't write about it earlier, because I found it so absolutely handy.
In theory, this should be handled at the operating system level rather than the application level.
Thanks very much.
I'll keep my fingers crossed. I can't hold my breath if I'm the only interested party though ... unless ... you accepting bribes? Beer? Redskins tickets? Popcorn? :-)
>> In theory, this should be handled at the operating system level rather than the application level.
>> Rybka was just sleeping in mid-search. Maybe we'll bring it back for Rybka 4.
It's probably clear from my other posts on this topic that I'm lobbying for this to be handled in practice as well as in theory at the operating system level rather than the application level.
The GUI's should have a switch that users can select (or not) to run engine processes at Below Normal priority, and the GUI's should be well written enough to give the engine as much of the machine as possible, in particular: as much when the engine is run at Below Normal as when the engine is run at Normal.
Engines should not have to do Sleep(0) much less Sleep(1) to compensate for GUI's that don't give the user an engine priority switch or GUI's that chow down on CPU.
For whatever reason, handling this problem doesn't work on my system as you are describing it - I wish it did. However, Vas' 'procedure' in limiting CPU use works perfectly on my system (at least). Perhaps it is because my CPU is a few years old - perhaps whenever I decide to get a new computer with the latest and bestest chips and a 64-bit operating system this problem will go away but right now I have it.
I described this in words to Svilponis, but now I can't find my post anywhere, but I will attempt to also stick some images in here because they are pretty self-explanatory.
(All the following with Rybka2.3.2a w CPU setting)
01) With TaskManager, set Rybka to LowPriority and CPU setting to 100%. Set Rybka to work. CPU pegs out to 100%, and there are intermettent system freezes with non-CPU intensive apps.
02) In the EngineParameters utility, set CPU=95% (actually 98% works pretty well, too, but it's easier to see at 95%).
03) Rybka now set to NormalPriority (I tried it also at LowPriority and it looks exactly the same as here in case you wonder). The CPU is indeed operating, on average, at about 95%. It varies about of a range of ± a few percent. Rybka is evaluating now at almost full speed, just a few seconds slower than normal, but fine for static evaluations (non-competitive use). There are now absolutely NO intermittant system freezes when I use non-CPU intensive apps (no Photoshop!).
[img]3_Rybka2.3.2a 95pctCPU_TaskMgr .jpg[/img]
For me, this is very nice.
So --- at least with my system this little CPU switch makes my life a lot easier when running a long analysis - the slight increase in time for analysis is perfectly acceptable. For whatever reason, setting RYBKA (and Aquarium, and DeepFritz10) to LOW PRIORITY does not help me at all. Running Rybka with 100% cpu always pegs it. I realize this is may be an artifact of my system, but the CPU setting helps it.
The question remains though - for those whose lower PrioritySettings "get the cat out of the tree" - how does having a CPU setting (that is set to 100% by default) you never touch hurt you in any way whatsoever??
>> The question remains though - for those whose lower PrioritySettings "get the cat out of the tree" - how does having a CPU setting (that is set to 100% by default) you never touch hurt you in any way whatsoever??
As long as there is a setting set to 100% by default, then in my case I'd never touch it and I could live with it.
Somewhere in the engine there will have to be some code that does something like
If settingsSandallsPriority < 100 Then
Sleep(0) ' or maybe even sleep(1) is needed to fix things on your machine
and I have to pay CPU cycles to execute that If-Then statement fairly often for the code to have a helpful effect for your machine.
The additional cost of a repetitively executed If-Then on my machine to step around that Sleep() would hurt me in the way of lost CPU cycles, but having thought about this again, I expect that cost is negligible and would be acceptable to me. Actually having to execute the Sleep() API calls is what I really don't want to have to live with.
Your thoroughness and persistence are laudable. They drove me to think this the rest of the way through.
>> this should be handled at the operating system level
Absolutely. In the world of 3D graphics rendering, rendering engines routinely consume 100% of multiple CPUs for days on end.
So: Some 3D renderers have a user-settable render-at-lower-priority switch.
For example Maxwell Render has a low-priority render setting. You can visit http://www.maxwellrender.com/ then click Downloard on the left, then click Manuals, and downlod the manual. They are in Spain, I am in Seattle WA USA, and for me the download is 10 seconds on a cable modem. Couple of seconds to unzip and load into Adobe reader, see the low priority switch on page 91.
The Maxwell forums indicate that most Maxwell users enable the low-priority switch so that they can use their computers to do email or whatever while a render is cooking at a lower priority. They just need to keep it in mind not to use their machine too much if they are trying to get that render to the customer on a tight production deadline.
A virus-scan kicking in or Apple-software-updater or Adobe-updates or Windows-updates kicking in can be bad for meeting that deadline, since all of those will take precedence over low-priority rendering or low-priority chess analysis.
Rybka users playing chess games on a server of course would not want to use low priority, but for casual use it's very handy.
Did you know: If an engine like Shredder or Rybka is consuming 100% CPU at normal priority on an XP or Vista machine, and you walk away for a couple of hours, then come back and your screen saver has kicked in, and your screen saver is set to require a password to get back to your desktop, then you are going to see some really long delays while the OS scrounges enough CPU cycles away from that hungry chess engine (or 3D renderer) to present you with the dialog box for your password, and check your password before you get back on. If you weren't expecting this, you might think your machine had hung.
Rybka users on Windows could experiment with Task Manager. Find the Rybka processes, right click and choose Set Priority\Below Normal. I only ordered my copy of Rybka 3 from Convekta today, so I can't recite things like process names to look for.
I should think people experimenting with lowering Rybka priorities using Task Manager would want to ensure they find all Rybka processes and lower them to equal priorities. Intuition isn't always right, but intuitively, it seems like having MP Rybka run one engine process at a higher priority than a sibling engine process is just begging for trouble.
If Vas or other forum gurus here start screaming "No Don't Change Priorities in Task Manager" please listen to them, ignore me.
Some years back I wrote my own little interface to Fruit - not a GUI, more like a tool to batch-analyze EPD positions and store the results in a SQL database. Rybka looks interesting enough that I plan to dust off my little interface and use Rybka 3 to analyze EPD. The 'go minscore' UCI extension looks mucho interesting.
It's unlikely, but in case anyone cares, here are some applicable code snippets for how a GUI author working with the Windows .NET class library can start a process for a UCI engine, set it to Below Normal priority, start a separate thread in the GUI to handle fetching engine output, set that thread to Above Normal priority so that no other GUI task will ever cause the engine to wait on the GUI, and use a .NET synchronized queue to ensure the two GUI threads don't trip over each other. Using these straightforward .NET constructs my humble interface got slightly more nodes-per-second than the excellent Shredder GUI, first time out of the chute, no performance tweaking needed from me. I just rely on those .NET guys to make their stuff fast enough.
I'm sure this kind of thing is also easy in other development environments, it's just that I happen to have had work in .NET, so that's what I used due to familiarity. And Visual Basic is used for the same reason, but the code could easily be transliterated into C# or even into the new and interesting F#.
Private threadEngineOutputReader As New System.Threading.Thread(AddressOf KeepOnGettingEngineOutputs)
Private qEngineOutputs As Queue
Private synchqEngineOutputs As Queue
threadEngineOutputReader.Priority = ThreadPriority.AboveNormal
qEngineOutputs = New Queue()
synchqEngineOutputs = Queue.Synchronized(qEngineOutputs)
Dim s As ProcessStartInfo = New ProcessStartInfo
.FileName = sFruitPathAndExe
.Arguments = ""
.WorkingDirectory = sFruitPath
.UseShellExecute = False
.RedirectStandardInput = True
.RedirectStandardOutput = True
.CreateNoWindow = True
.StartInfo = s
swWriteInputsToEngine = .StandardInput
srReadEngineOutput = .StandardOutput
' Wait for engine to initialize - just poll to see when CPU drops off
For I As Integer = 1 To 100
If sngCPU_Usage() < 3.0 Then
.PriorityClass = ProcessPriorityClass.BelowNormal
Dim pUCI_Engine As Process() = Process.GetProcessesByName(sFruitNameForEXEandProcess)
pUCI_Engine(0).PriorityClass = ProcessPriorityClass.BelowNormal
Private Sub KeepOnGettingEngineOutputs()
Dim sRet As String
Do While bRunning
sRet = srReadEngineOutput.ReadLine ' This read blocks, which is why this read is on its own thread
>In theory, this should be handled at the operating system level rather than the application level.
Ideally it could be handled at either level - in practise, it is handled at neither. :) And I wouldn't count on the OSs doing much: back in 2001, Dan Bernstein was prognosticating that idle cycles would be a "thing of the past" within a year... well, maybe at least with Linux (all the technology is there - it will just be a administrator decision regarding how to use idle time, with some philanthropes probably getting in on it, sorta like screen savers); and in 2004, immune to the need of finding a non-lazy kernel hacker who cared enough about this, he again said that idle time would be a "thing of the past" within a year.
I don't know how Vas implemented this, but it worked (for me anyway) like a champ. I guess I was the only one using it. I miss it - even now, as this screen freezes up for 15-20 sec at a time as I run IDeA on an interesting line. If I run 2.3.2a, I have no such problem. But the analysis from R3 is better for these things, so I have no good choice but to use R3.
> Good question, but ... well, because those settings are very inefficient. They slow Rybka down FAR more than is necessary.
I believe "Normal" priority is much more efficient than the scheme you suggest. Rybka3 is currently running on my computer. When I'm not typing, Rybka uses 98%-100% of the CPUs. When I'm typing or clicking on a link in Firefox, Rybka uses 95%-98% of the CPU. Thus "Normal" provides adaptive behavior which should slow Rybka down less than setting it to always use 95% of the CPU and leaves your computer ultra-responsive.
I've experimented with "High" and "Real Time" priorities for Rybka but they never seem like a good idea. Basically, they tell the OS that Rybka is more important than the Aquarium GUI, Chessbase GUI, or your web browser, preventing you from seeing or interacting with the analysis or doing anything else simultaneously while Rybka is running--the bad behavior you're seeing. If you set it to "Normal" (or maybe even "Above Normal") you can choose to do something else or leave the system entirely for Rybka.
I rarely use "Low" priority so I can't say much about it.
>> those settings are very inefficient. They slow Rybka down FAR more than is necessary.
Setting a Windows NT/2000/XP/Vista process to Below Normal Priority does not slow down that process.
Let's say you're just endlessly evaluating the chess starting position, and Rybka is running at Normal priority, and you're getting 100knps.
If you set Rybka to run at Below Normal priority, you should still get 100knps, provided you do not add any additional work for the computer to do at any priority higher than Below Normal.
In NT/200/XP/Vista the rule is simple: If a thread is ready to run and there is not currently an available core/CPU, and the thread's priority is higher than a currently running thread, then the currently running thread gets kicked off the CPU and the higher priority thread gets to run.
It is possible that the GUI you were using burns up a lot of CPU cycles repeatedly checking for UCI engine output. Then, if Rybka was bumped down to Below Normal and the GUI is still at Normal, the GUI could waste a lot of machine time polling for output that the engine hasn't yet produced. Any output yet? Any output yet? How about now? Huh? Now? and because the higher priority GUI is taking a lot of CPU the engine gets fewer chances to produce output to hand off to the GUI. But GUIs should not poll, they should block a thread on pipe reads so the operating system can efficiently un-block the read when the engine has produced something.
Good point about the GUI polling thing, but it seems directly tied to engine use. Nice explanation though - I'll keep it in mind. The GUI's a am using are Aquarium (R3 for now) and DFritz10 (both R3 and R2.3.2a). Same response with both, by the way.
2) Rybka2.3.2a, LowPriority,100%cpu(default); both cpu's at 100% - other apps freeze periodically.
3) Rybka2.3.2a, NormalPriority, 95%cpu (my stg); both cpu's at 94-97%. -other apps work fine. Rybka evals only slowed slightly (5%?).
For my system, those are the hard facts.
I understand what you're saying. Whenever I upgrade my computer at some point in the future I may be able to do things the way you describe but for the forseeable future I have what I have. It sounds like you have experience running the Rybka 2.3.2a at a high but less than 100% CPU setting and have compared the results compared to adjusting your Priority Setting. It ain't how it works here, is what I'm saying. Much appreciate your help - all of you. Thanks and regards.
I have a mini tower case with D945 (dual P4), and if only one core has to run permanent analysis - in other words, 50% cpu - then it does not need full fan speed. Unfortunately, if I run engines on both cores, the fans run full speed after a while and are quite loud. But I have read the Core 2 cpus produce less heat than older intels.
Maybe you can install a bigger or better cpu heat sind and/or cooling fan?
(On another computer where I have an AMD cpu , that didn't help though. I must underclock it...)
I think what happened is that when i leased this computer, I payed extra to get a super fast chip, and the leasing company put the faster chip in without also upgrading the cooling system. Pricks. this is the last time i go with a lease.
by the way, here is the best site i could find on undervolting. The cite has excellent links to software that assesses performance and heat and other cool things.
ps., when you use the one processor version of rybka in a dual core, does it use all of one processor, or does it use a bit of both processors?
Definitely. When I assembled my computer I spent a few hours testing it at idle and max load to set appropriate fan speeds (a trade-off between cooling and noise). Last night I successfully set a mild overclock (2.2GHz -> 2.4GHz) and again, monitoring the temperature of all the components was a critical step.
this undervolting is expected to have no impact on performance. I'll test this assumption, once i've reduced the volts a bit more and confirmed system stability
undervolting seems like a good solution ot heating issues
>>my cpu is getting way to hot when running rybka (even on one processor). over 90 c.
> Why don't you just set the process priority using the GUI or OS? [partially answering a different question]
There occasionally seems to be a bit of confusion regarding the terminology in this thread, so maybe I could help clarify something. "Priority" is a means for the OS to judge what percentage of available CPU time to give competing processes - but when there is (effectively) only one working process, it can get 100% of the CPU time even if it has a low priority. In the case at hand, so as to avoid the overheating, it would be desired that the OS (or Rybka directly) could also do something such as: allocate 10% of time to idling.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill