Implementation of the "time per move" time control

[Ilari Pihlajisto]

I'm wondering what the correct way to implement the "st" command in a GUI is. I have some questions that the protocol specification doesn't answer clearly:
- Can a "time per move" time control be used in combination with a traditional time control, or are they mutually exclusive?
- Should the GUI send the engines the "time" and "otim" commands?
- Why does Xboard send completely unrelated "time" and "otim" values to the engines when using an "st" time control? Xboard 4.4.3 does not send a "level" command (as it shouldn't), but for some reason it sends "time 30000" and "otim 30000" before each move, even though the "st" value is 2 seconds. This doesn't seem to have any effect on how the engines use time. The command I tried is "xboard -fcp crafty -scp crafty -mg 1 -st 0:2".

Thanks.

[H.G.Muller]

The st and level commands are mutually exclusive. (Unlike sd, which defines an additional limitation, and can be combined with either level or st.) In fact I am considering to extend the protocol specs for level, so that currently invalid combinations of the (MPS, TC, INC) parameters define the equivalent of an st command. This could be useful in a multi-session time control, where you could, for instance, have a first session of 40 moves in 1 hour, followed by a session where you have 10 sec maximum per move. This could of course be done with existing engines, by sending them st after move 40. But some engines would prefer to know in advance which sessions to expect, and the multi-session version of the level command we will define for that should be able to warn that an st session is upcoming.

One way to do it would be to let a negative value -P for the increment signify an increment of maximally P sec/move, but never more than you spent on the previous move. Then level 0 0:10 -10 would be equivalent to st 10, and level 0 1 -10 would specify a Bronstein TC with a delay of 10 sec.

OK, I guess that was digressing a bit. It seems an obvious bug that WinBoard 4.4.x sends wrong time and otim comamnds in -st mode. This mode is not really supported in 4.4.x (and earlier): the clocks do not run, and the GUI will not forfeit engines on time even with -autoCallFlag true. I guess engines have learned to live with this, and implement the TC fully independently. (I guess this is feasible, because there cannot be an accumulation of timing errors.) It is very undesirable, however, that in this process they have to ignore time and otim, because wrong values are being sent.

Sending time and otim before the move is not so redundant as it seems, despite the fact that they should always send the same value, because it has better resolution as the st command. (This of course could also be solved by allowing the st command to send a float.) I would recmmend that GUIs do send such commands, but with the correct value.

Anyway, the current deveopment version is the first WinBoard version that really implements fixed-time-per-move TC, rather than delegating it to the engines: it operates the clocks, enforces the time limits, and sends time with the proper value (and otim with the time the opponent had left on its clock after the last move, as the clocks reset at the start of the move). If you look at WinBoard, I think you should use that as a model. A good version can be downloaded from http://hgm.nubati.net/WinBoard-4.5.beta.zip .

[Ilari Pihlajisto]

Thanks, that answers my questions. I'll try the latest Xboard and use it as a reference implementation.