OpenChess

Anyone seeing the reported Time Management errors while testing Houdini? According to the report, the clock will stop while Houdini is thinking and won't restart until Houdini moves.

Here's the report from NATIONAL12: "Date 2010-12-17 22:26
i appear to have found a fault in Fritz GUI when operating engine matches with Houdini.often Houdinis clock will stop when engine is at x depth and it will look through alternative moves with no use of time and then post move with original time when clock stopped.i have noticed this at least half a dozen times but did not wish to comment until i was sure of my facts.this would be impossible to see in fast blitz games.i only noticed it at 15+10.it does not happen with Rybka."

jb

From what I've read, for the Fritz GUI to function correctly you need to put the process priority of the engine to "lower than normal".
The GUI controls the operations and should have a higher thread priority than the engines.

Robert Houdart wrote:From what I've read, for the Fritz GUI to function correctly you need to put the process priority of the engine to "lower than normal".
The GUI controls the operations and should have a higher thread priority than the engines.

It's still strange behavior, even if changing the process priority is a workaround. Threading deadlock in the GUI thread? I haven't seen this myself, though. Just wondering if there's anything to the report.

Thanks,
jb

I have not messed with priority and cannot reproduce this so-called time management manipulation posted by a self proclaimed Rybka fan-boy. Needless to say that GUI controls time management. One wonders if he's playing ponder on games on the same machine. But anyways just seem like priority issue and more than likely a GUI problem.

Jeremy Bernstein wrote:It's still strange behavior, even if changing the process priority is a workaround. Threading deadlock in the GUI thread? I haven't seen this myself, though. Just wondering if there's anything to the report.

On the contrary, it is the *expected* behaviour. If you have X cores, and are running an engine with X CPU- and memory-intensive threads, Windows cannot give the slightest guarantee that the GUI process will be able to get enough CPU time to perform its job.

There are two easy solutions:
- run the engine with one thread less than the number of cores, leaving one core free for the GUI or other stuff that is running in Windows;
- make sure that the GUI has higher process priority than the engines.

I don't use the Fritz GUI, but in Arena and Shredder I always run the engines at lower than normal priority.

Robert Houdart wrote:

Jeremy Bernstein wrote:It's still strange behavior, even if changing the process priority is a workaround. Threading deadlock in the GUI thread? I haven't seen this myself, though. Just wondering if there's anything to the report.

On the contrary, it is the *expected* behaviour. If you have X cores, and are running an engine with X CPU- and memory-intensive threads, Windows cannot give the slightest guarantee that the GUI process will be able to get enough CPU time to perform its job.

There are two easy solutions:
- run the engine with one thread less than the number of cores, leaving one core free for the GUI or other stuff that is running in Windows;
- make sure that the GUI has higher process priority than the engines.

I don't use the Fritz GUI, but in Arena and Shredder I always run the engines at lower than normal priority.

Windows won't completely starve a process. It uses dynamic scheduling priorities, exactly as taken from the old VMS operating system when MS hired some of that group for the original windows NT project. As a process sits in the ready state, wanting CPU cycles, it's priority rises as the currently executing processes see their priorities fall. Unless you go nuts with too many threads, the GUI should not "starve for seconds", only for "fractions of a second" worst-case...

If you have 4 cores and you run two engines with 8 or 16 threads each, you might see significant slowdown. But simply running 4 threads per chess engine, pondering, on a 4 core CPU only gives you 9 processes to shuffle thru the CPUs. That should not cause problems unless you run at impossibly fast time controls when timeslice values will cause problems unless you tune the process scheduler to use much shorter quantums.

Now if the GUI does something ugly like continually "polling" for input, rather than blocking and hanging on a read, then things can get a bit worse. But only an idiot would program a GUI to intentionally be CPU bound since it would interfere with real games if you run it on a single-core box where it now competes for CPU cycles with the engines as they get their turn in the CPU.;..

Irrespective of whether the GUI has been programmed by an idiot or not, the point is that it makes a lot of sense to give the GUI a higher priority than the UCI engines it's controlling.
What some call a "work-around" should really be the standard way of running a chess GUI in Windows.