WB protocol: pause / resume

[hgm]

I have just implemented the commands pause / resume as described in the WB protocol specs in XBoard / WinBoard. (In my source repository master branch; no binaries yet.) This means the Pause (P) button in the button bar now also does something when you use it when the engine is on move or pondering (in human-engine or engine-engine games).

What it does in detail is this:

If the thinking engine supports 'pause' (which it announced by sending feature pause=1 at startup), pressing P will cause pause to be immediately sent to the thinking engine, and will stop the clocks. If there is an opponent engine it will also receive pause, if it supports it. If not, and pondering is on, it will receive an easy command to turn its pondering off.

If the thinking engine does not support 'pause', pressing the P button will only pause the engine after it finishes thinking about the current move, and the clocks will only be stopped then. XBoard will defer processing of the move until you unpause by pressing P again. In particular the move will not be relayed to the opponent. If it is a ponder game, the engine (and possibly the opponent engine), will receive an easy command to stop its/their pondering.

When unpausing, engines stopped with pause will receive a resume command, those stopped pondering with easy will receive a hard command.

For this to work well, it is essential that engines that don't support 'pause' react immediately to the 'easy' and 'hard' commands, by aborting an ongoing ponder search, or starting a new one, respectively. Rather than just setting a flag that controls whether they will ponder after the next move. If you use them in ponder-on games, that is. In ponder-off games the 'easy'/'hard' commands will not be used when pausing.

UCI2WB does support 'pause' now; it implements it by sending a 'stop' command to the UCI engine, (and ignoring the 'bestmove' response), when it receives 'pause' from a WB GUI. And it will start a new search (ponder or thinking, depending on which side is to move) with the same parameters (except possibly updated time of the thinking engine) as the one that was aborted. The assumption is that they would be able to pick up the search from the hash table where it was aborted, so they don't receive any time compensation for being disturbed. If they can't, tough luck!

[michiguel]

I have just implemented the commands pause / resume as described in the WB protocol specs in XBoard / WinBoard. (In my source repository master branch; no binaries yet.) This means the Pause (P) button in the button bar now also does something when you use it when the engine is on move or pondering (in human-engine or engine-engine games).

What it does in detail is this:

If the thinking engine supports 'pause' (which it announced by sending feature pause=1 at startup), pressing P will cause it to be immediately sent to the thinking engine, and will stop the clocks. If there is an opponent engine it will also receive 'pause', if it supports it. If not, and pondering is on, it will receive an 'easy' command to turn its pondering off.

If the thinking engine does not support 'pause', pressing the P button will only pause the engine after it finishes thinking about the current move, and the clocks will only be stopped then. XBoard will defer processing of the move until you unpause by pressing P again. In particular it will not be relayed to the opponent. If it is a ponder game, the engine (and possibly the opponent engine), will receive an easy' command to stop its/their pondering.

When unpausing, engines stopped with 'pause' will receive a 'resume' command, those stopped pondering with 'easy' will receive a 'hard' command.

For this to work well, it is essential that engines that don't support 'pause' react immediately to the 'easy' and 'hard' commands, by aborting an ongoing ponder search, or starting a new one, respectively. Rather than just setting a flag that controls whether they will ponder after the next move. If you use them in ponder-on games, that is. In ponder-off games the 'easy'/'hard' commands will not be used when pausing.

UCI2WB does support 'pause' now; it implements it by sending a 'stop' command to the UCI engine, (and ignoring the 'bestmove' response), when it receives 'pause' from a WB GUI. And it will start a new search (ponder or thinking, depending on which side is to move) with the same parameters (except possibly updated time of the thinking engine) as the one that was aborted. The assumption is that they would be able to pick up the search from the hash table where it was aborted, so they don't receive any time compensation for being disturbed. If they can't, tough luck!

You can try this with Gaviota. I have implemented pause a long time ago. It pauses it and resumes it _exactly_ at the same point since it does not rely on the hashtable but it locks the search waiting for resume.

Miguel

[hgm]

Ah, great!

For UCI I have to abort the search and start a new one, as I don't think there is anything like a 'pause' command in UCI.

[hgm]

I have uploaded Windows binaries now to http://hgm.nubati.net/WinBoard-4.7.beta.zip . (Contains winboard.exe + UCI2WB.exe.)

[Giorgio Medeot]

Hi,
I tried this version, but I experienced some little glitch:
first I leaved in my settings file the line

Code: Select all

/viewerOptions="-ncp -engineOutputUp false -saveSettingsOnExit false"

I then tried to launch Winboard (double clicking on the executable), and I got an error popup saying "Game not found in file".
Then, as I wanted it to open in cp mode by default, I replaced the above line with

Code: Select all

/viewerOptions="-cp -fcp gaviota-0.85.1-win64.exe -fd ..\gaviota -scp stockfish-231-64-popcnt-ja.exe -sd ..\stockfish -sUCI -saveSettingsOnExit false"

This time I got again the same error, with a second popup saying "Startup failure on 'gaviota-0.85.1-win64.exe': The system cannot find the file specified."
If I try to load the engine from the Load First Engine dialog, it works.

The previous version I had didn't expose this behavior, but I can't recall which version exactly it was (it should have been one of the latest, anyway).

Hope it helps,
cheers

• Giorgio

[hgm]

Hi,
I tried this version, but I experienced some little glitch:
first I leaved in my settings file the line

Code: Select all

/viewerOptions="-ncp -engineOutputUp false -saveSettingsOnExit false"

I then tried to launch Winboard (double clicking on the executable), and I got an error popup saying "Game not found in file".

The -viewerOptions are only looked at when WB is started with the option -viewer (in stead of -ncp or -ics). This should never happen when you click WinBoard. Only the command associated with PGN files should invoke WB this way, when you double-click a PGN file.

What you describe sound almost like WB tries to open its own .exe as a game file, when you double-click it, because of a wrong association of .exe files. But it baffles me how you could ever obtain such an association. Just replacing the .exe should never make any new associations...

Then, as I wanted it to open in cp mode by default, I replaced the above line with

Code: Select all

/viewerOptions="-cp -fcp gaviota-0.85.1-win64.exe -fd ..\gaviota -scp stockfish-231-64-popcnt-ja.exe -sd ..\stockfish -sUCI -saveSettingsOnExit false"

This time I got again the same error, with a second popup saying "Startup failure on 'gaviota-0.85.1-win64.exe': The system cannot find the file specified."

This is consistent with your mouse clicking somehow invoking WB with an option -viewer (or the -viewerOptions would have been ignored, which they obviously are not). The error message is probably due to incorrect use of backslashes (in filenames) within quotes (where they are interpreted as escape character). You should use a pair of backslashes to represent a single one.

But the first error is that this command would be invoked at all by double clicking. Calling WB with an argument that is not an option (like "winboard foo") will be interpreted as "winboard -viewer -lgf foo", and dragging the file foo on top of winboard.exe will cause Windows to issue the former command.

So it seems that your double-click is interpreted as if you dragged winboard.exe onto itself???

If I try to load the engine from the Load First Engine dialog, it works.

The previous version I had didn't expose this behavior, but I can't recall which version exactly it was (it should have been one of the latest, anyway).

Hope it helps,
cheers

• Giorgio

For me the beta version also does not have this problem, on all systems where I tried it (Win2K, Win XP, Win 7). Perhaps I should make a version that shows a popup with the command line that was used to invoke WinBoard, so we can be sure what happened.

[hgm]

OK, I made a test binary ( http://hgm.nubati.net/test.zip ), which always starts with a popup note displaying the command-line options with which it was called (between ><). Please try what that does.

[Michel]

You can try this with Gaviota. I have implemented pause a long time ago. It pauses it and resumes it _exactly_ at the same point since it does not rely on the hashtable but it locks the search waiting for resume.

How do you implement the clocks? GnuChess uses a timer based on gettimeofday for that. It would have deduct the time spent while paused. Or is there a more elegant solution?

[michiguel]

You can try this with Gaviota. I have implemented pause a long time ago. It pauses it and resumes it _exactly_ at the same point since it does not rely on the hashtable but it locks the search waiting for resume.

How do you implement the clocks? GnuChess uses a timer based on gettimeofday for that. It would have deduct the time spent while paused. Or is there a more elegant solution?

When it is paused, a second clock starts and measures how much time elapsed, and this is discounted from the total time. I do not think there is any other (more elegant) way around it. It is not too clumsy though, I have all this encapsulated in proper functions. The whole program does not see any of this .

Miguel

[hgm]

I don't think there is need to use anything different from how the engine normally accounts time. The simplest way to do it is probably to add the paused time to the start time of the search. I.e. read the time at 'pause' and subtract it from startTime, then read the time at 'resume', and add it.