If gnuchess is invoced by xboard the CPU load increases to 100%, even when waiting for the users move. Which looks like some kind of busy waiting. ps -l F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 1000 6900 4672 0 75 0 - 3821 wait pts/1 00:00:00 bash 0 S 1000 6940 6900 0 75 0 - 5662 - pts/1 00:00:00 xboard 0 S 1000 6941 6940 0 78 0 - 2684 wait pts/1 00:00:00 gnuchessx 0 R 1000 6942 6941 94 85 0 - 4173 stext pts/1 00:01:28 gnuchess 0 R 1000 6963 6900 0 77 0 - 1887 - pts/1 00:00:00 ps
This is called pondering or thinking on opponent's time. You can disable it in "Options/Ponder Next Move" or by starting xboard with the -xponder option. Please close the bug it that was the reason.
Hi, I think i got a similar bug (i'll open a new report if really different) : - When running 'gnuchess' from console, the 'gnuchess' process takes 100% of the CPU. - When running 'xboard', nothing abnormal (fairymax loads the CPU only when computer is thinking). Dear submitter, could you check if the initial behaviour you described 5 years ago still occur and if you're not confronted to my behaviour ? Thanks,
Hi, I think i got a similar bug (i'll open a new report if really different) : - When running 'gnuchess' from console, the 'gnuchess' process takes 100% of the CPU. - When running 'xboard', nothing abnormal (fairymax loads the CPU only when computer is thinking). Dear submitter, could you check if the initial behaviour you described 5 years ago still occur and if you're not confronted to my behaviour ? Thanks,
Hello, Am 29.10.2012 20:01, schrieb manuk7: xboard uses now fairy-max. And CPU load goes low, while waiting for human player input. (Not tried with gnuchess) Greetings Juergen
5 years and no closure. This issue should be marked as severity > Important. It drains the battery for no good. I just yesterday saw upstream do a new release. Are they acknowleging this bug ?