UCI's readyok: A mistake or a misunderstanding

[AndrewGrant]

For reference in my post, the following is the quote from the UCI protocol found here (http://wbec-ridderkerk.nl/html/UCIProtocol.html)

* isready
this is used to synchronize the engine with the GUI. When the GUI has sent a command or
multiple commands that can take some time to complete,
this command can be used to wait for the engine to be ready again or
to ping the engine to find out if it is still alive.
E.g. this should be sent after setting the path to the tablebases as this can take some time.
This command is also required once before the engine is asked to do any search
to wait for the engine to finish initializing.
This command must always be answered with "readyok" and can be sent also when the engine is calculating
in which case the engine should also immediately answer with "readyok" without stopping the search.

The latter bolded text (my emphasis) says that whenever you recieve "isready", you must respond with "readyok". There is no option to say "No, I'm not ready!". However, it also says that "this command can be used to wait for the engine to be ready again", which to me suggests that you can see "readyok", and then hold off on responding "isready" until you are actually prepared to perform a search.

That is two say, there are two ways of viewing isready: #1 is a State Request. The GUI is asking us if we are ready, and its expected that we respond once we are. This might be instant, or upon completion of an existing search. #2 is that isready is really a ping/pong/heartbeat.

I like to see it as #1. In fact, I've coded it as #1, and I've not had any problems until just now, getting reports that one GUI is indeed using the command as #2. It is of no real difference to me, except right now doing it as #1 prevents a GUI or user from trying to launch a search ontop of an already running serach. In my mind, this is your problem and not mine, so it is all fine.

[CMCanavessi]

I agree that the wording is completely contradictory.
How I understand (or how I would use it) is in your #1 way when the engine is initializing (reading TBs, making the Hash, etc), which completely blocks the engine from doing any other thing wether you want it or not, and which by today's standards it's almost instant anyways (or pretty fast).
And then, when all that is already set up and the match has already begun and the search is going on, as #2: reply instantly if receiving isready, as it may be used as some sort of ping (like in Banksia's case).

[phhnguyen]

I explain here my view/BanksiaGUI view, of course not for justification but for our understanding.

Engine crashing happens quite often. Many crashes are stalls in which engines don’t quit but cease sending info to the chess GUI, even other things seem to be fine, the pipes between those engines-chess GUI look OK. As a normal user or tester, we don’t want to wait until the game is over by timeout since that may be long, boring, annoyed, waste our resources for almost nothing. Waiting (for timeout) is not an option for some timers such as depth, nodes either. That’s why ping/pong and similar commands can help.

In the case of Banksia GUI, it doesn’t disturb engines IF it frequently receives something from them. It may send a ping/isready to an engine if it got nothing for a while (30s) and then waits for another period (40s - total 70s after the last receiving) before deciding the engine crashed.

If you want those commands ping-pong/isready-readyok work as “wait for me”, there’s almost no point why we need them (chess GUIs can simply wait), especially for UCI protocol (Winboard protocol uses ping/pong as a “wait” when the engine’s initializing but UCI has the command uciok instead) and then we don’t have any mechanism to detect crash-stalls of engines.

For BanksiaGUI, one point we may consider discussing and changing is that what the threshold/period BanksiaGUI should wait before sending isready to check the engine and the period to decide the engine is crashed. The current periods (30s/70s) of BSG were made based on some testing and experience.

For the benefit of users, as a chess GUI developer, I humbly suggest engines’ developers use commands isready/readyok as pure ping/pong to help chess GUIs/users to detect the crash-stalls problems, regardless of the exact meaning of some paragraphs in documents. It is not a hard task for engine developers nowadays since they usually use multi-threads in their engines.

[Ferdy]

I believe it has two main purpose, to allow the engine to be ready before a search and to check if the engine is still alive in a case where isready is sent while the engine is supposed to be searching.

From interface's perspective an engine that does not reply to isready is problematic and can be considered as dead or probably a non-compliant uci engine.

A sample situation is when an engine spends more time than its remaining time searching, interface would send isready if engine cannot reply with isready then it probably crashed or it just becomes unresponsive. It is important for the interface to have full control of the engine.

There can be other reasons why an interface sends isready while the engine is supposed to be searching. BTW which interface is sending isready while the engine is searching? It is good to know its purpose.

Put up a guard not to search if you are already searching.

From uci specs.:

Code: Select all

* isready
	this is used to synchronize the engine with the GUI. When the GUI has sent a command or
	multiple commands that can take some time to complete,
	this command can be used to wait for the engine to be ready again or
	to ping the engine to find out if it is still alive.
	E.g. this should be sent after setting the path to the tablebases as this can take some time.
	This command is also required once before the engine is asked to do any search
	to wait for the engine to finish initializing.
	This command must always be answered with "readyok" and can be sent also when the engine is calculating
	in which case the engine should also immediately answer with "readyok" without stopping the search.

[phhnguyen]

There can be other reasons why an interface sends isready while the engine is supposed to be searching. BTW which interface is sending isready while the engine is searching? It is good to know its purpose.

Banksia/BanksiaGUI do that!

The purpose is to detect crash-stall when an engine does not quit but stops reply. Banksia GUI does not send the command "isready" if it receives frequently some info from an engine but starts sending that after a period (30s) of receiving nothing then concludes the engine has crashed after waiting another period (40s). Without doing that, we may waste resources for nothing or even wait forever for stalled engines when timers are depth or nodes.

In the view of users and software developers, there is no difference between the none and searching stages. We need some ways to detect crash-stall problems anyway.

[CMCanavessi]

There can be other reasons why an interface sends isready while the engine is supposed to be searching. BTW which interface is sending isready while the engine is searching? It is good to know its purpose.

Banksia/BanksiaGUI do that!

The purpose is to detect crash-stall when an engine does not quit but stops reply. Banksia GUI does not send the command "isready" if it receives frequently some info from an engine but starts sending that after a period (30s) of receiving nothing then concludes the engine has crashed after waiting another period (40s). Without doing that, we may waste resources for nothing or even wait forever for stalled engines when timers are depth or nodes.

In the view of users and software developers, there is no difference between the none and searching stages. We need some ways to detect crash-stall problems anyway.

I agree with what you´ve said and with your use of the isready command to check if the engine is still alive. I think in this particular case, the problem was 2-fold:
1) Ethereal was not instantly responding to the isready command (already solved in a new version that AGE sent me to test)
2) Ethereal is quite silent when searching. It prints an info string when it gets to a new depth but that´s it, and as it goes deeper and deeper, the time to get to a new depth increases and it can take quite a while to get a new message, even if the engine itself is perfectly ok and calculating non-stop. That´s why I told AGE that it may be a good idea to print some sort of information every X seconds, like a lot of other engines do.
For example, Komodo prints lines like this every 3 seconds, regardless of what it´s doing:

Code: Select all

info nodes 67813640
info nodes 72208771
info nodes 76725672
info nodes 81362579

Houdini prints an info line every second, and so on.
That would have avoided this issue (though the main isready thing would still be a problem in other cases).

What caught my attention however is how Banksia handled this. Instead of ending the game and flagging it as a crash/stall, it just took Ethereal´s last info string´s move and played that instead, and then gave Ethereal the ponder command based on the 2nd move of the last Ethereal´s info string. I don´t quite agree with this behaviour and I think it´s a bit non-elegant (it can sort of skew match results), but it´s of course arguable.

[AndrewGrant]

For the benefit of users, as a chess GUI developer, I humbly suggest engines’ developers use commands isready/readyok as pure ping/pong to help chess GUIs/users to detect the crash-stalls problems, regardless of the exact meaning of some paragraphs in documents. It is not a hard task for engine developers nowadays since they usually use multi-threads in their engines.

Agreed. Up until today, I had not seen a GUI or tool use the commands as actual pinging mechanisms.

[Fulvio]

I agree that the wording is completely contradictory.

To me it seems quite simple and logical: the engine should send "readyok" as soon as it is ready to accept a command.
When calculating the engine is (usually) ready to accept the "stop" command, so it should reply immediately with "readyok".

[AndrewGrant]

I agree that the wording is completely contradictory.

To me it seems quite simple and logical: the engine should send "readyok" as soon as it is ready to accept a command.
When calculating the engine is (usually) ready to accept the "stop" command, so it should reply immediately with "readyok".

Sure. But "simple and logical" is not the word for it. Your bolded text depends upon it being ready to accept A command, as in "At least one of the commands contained in the engine", as opposed to being ready to accept a command, as in "Ready to take on any new actions". The amount of intent conveyed by a single letter is unusual.

[hgm]

The readyok response should be sent whenever the input loop tries to execute a new command, and encounters the isready. During search the input loop should always be ready to accept a command, as a 'stop' could arrive.