WB protocol extension: play on node count

[hgm]

The next Winboard release (4.3.14) will implement a protocol extension to allow play based on engine node count. Using the node count as a time measure might be desirable under conditions where the wall-cock time is too inaccurate (i.e. very fast, sub-second games), or where there is a heavy, unpredictable load on the same core, which competes with the engine for CPU time. It can also be used to help reducing non-determinism from the engine, by eliminating clock jitter as a source of randomness.

The new WB command is:

nps N

where N is an integer number defining the engine clock mode. It will be sent to the engine directly after the 'level' command if the engine should use anything other than wall-clock time for its timing decisions, and its effect should remain valid until the next 'new' command. So in the engine, a 'new' command should set the clock mode to 'wall-clock'.

If N equals zero, the engine should use user CPU time (as can be obtained from calling the clock() function) as a time measure for timing decisions, and also use this time while reporting its thinking output (in reaction to the 'post' command). This in order to make WinBoard aware of the time the engine actually got assigned by the OS, (which might be smaller than the time elapsed), so WinBoard can use it to decrement the clock of that engine.

If N>0, it represents a (virtual) speed in nodes-per-second the engine should assume to convert its node count to time, and use that (virtual) time to make its timing decisions. WinBoard will do the same conversion on the number of nodes the engine reports, and use it to decrement the clock for that engine. The engine should report the search time as user CPU time, though, like with 'nps 0'! (It would be pointless to report the tim derived from the node count, as the node count itself is already reported).

Example: If the engine receives 'nps 100000', and has searched 800,000 nodes in 2 sec, using 50% of the CPU (so 1 sec of CPU time), it should assume it has thought for 8 seconds (800,000/100,000), report 100 as time (1 sec = 100 centi-sec), and 800,000 as node count.

Note that the 'nps' command can be used to give the engine time odds, if the set value deviates from the true nps the engine is making. To set a fair value is the responsibility of the user (as engines might count their nodes differently anyway).

My engine Joker 1.1.14(h) implements the nps command as described here.

An alpha version of WinBoard 4.3.14 can be downloaded from my website, as

http://home.hccnet.nl/h.g.muller/alpha.tst

The nps feature can be selected through the command-line options /firstNPS=N and /secondNPS=N, (depending on which engine you want to apply it to; different engines might need different nps for fair representation of their strength). The default value of the option is N = -1, and the option is not saved in the .ini file. (So if you start WinBoard, it will start in the normal wall-clock mode, even if last time you were playing on node count.)

The engine sould send the 'feature nps=1' to the GUI if it wants to announce that it implements this option. Currenty I don't check this , and WinBoard sends the 'nps' command to the engine unconditionally, if the user requests so. But it might be more user friendly to warn the user if the engine does not seem to support it, or even refrain from sending the 'nps' unless the engine explicitly says it will understand it. So future WinBoard versions might actually test for this 'feature nps=1'.

[hgm]

I guess a good policy fro protocol extensions like this one would be the following:

I do not want to define a new protcol version for any feature I add. There is really little need for that, as the existing protocol (version 2) does specify exactly how engines or GUIs should behave if the receive a command they don't understand (such as a command from a protocol they do not support). The engine would have to reply by:

Error (unknown command): nps

(say). If the GUI receives an unknown feature from the engine, it will answer by:

rejected nps

The protocol definition explicitly states that it is allowed for te engine to report request features that do belong to a highr protocol version than the one supported by the GUI. There is no excuse for an engine to send other protocol-violating stuff to the GUI (outside the features). Usually such stuff will be ignored by the GUI, and extending the protocol might break an engine by attaching an undesired effect to a formerly harmless protocol violation. As engines now can use the debug futures to 'comment out' their protocol-violating output (that many engines give for inclusion in the debug file), there really is no excuse for such behavior, and the problem of preventing it rests entirely with the engine author.

So in summary:
I will not feel inhibited to add new features to WinBoard, without stepping the protocol version. Engines that want to use these features should simply send the corresponding feature command at startup, for any protocol version >= 2.

If the feature only is supposed to affect what the GUI might send to the engine (e.g. use an extended level command for multiple time-control sessions), there is no need for the engine to check if the GUI accepts it: the GUI will either make use of the possibility opened by the engine, or it will not, and when it does, the engine is ready to understand it.

If the feature includes the use of engine->GUI commands (new ones, or altered syntax or meaning for existing ones), it is essential that the engine should check if the GUI accepted or rejected the feature, and refrain from using the command (with this altered syntax or meaning). The feature command in this case should be seen as a probe by the engine to find out if the GUI supports the feature.

The GUI can similarly probe if the engine knows a certain feature it faile to report about, by simply sending the questionable command to the engine. If it gets the "Error (unknown command): xxx" response, it will know that the engine does not support the feature, and can take appropriate action. The GUI thus does not have to show very much restraint in using protocol extensions. It should only refrain from using features that were exlicitly disabled by the engine.