xboard & time

[flok]

Hi,

With UCI you can say: here's a position, think for 2500ms to decide on a move.

How can I do this with the xboard/winboard protocol? Because "time" tells the engine the maximum time for the whole game.

[mar]

Try "st 250" (xboard uses centiseconds)

[flok]

Try "st 250" (xboard uses centiseconds)

Oh indeed! Totally overlooked that one. Thanks!

I found that st uses seconds and not centiseconds unfortunately. Also it is not explicitly stated if this should a whole second value or if that fractions (st 1.9) is allowed.

[mar]

I found that st uses seconds and not centiseconds unfortunately. Also it is not explicitly stated if this should a whole second value or if that fractions (st 1.9) is allowed.

Oh you're right! In that case my CECP implementation is broken...

[hgm]

Fixed maximum time per move is not a recommended mode for operating Chess programs: they become very wasteful in terms of CPU usage. I think it was a mistake that it was ever added to WB protocol. It is much better to allow the engine some freedom to distribute time over its moves.

For this reason I have no plans to extend the protocol in this direction.

[Joerg Oster]

Fixed maximum time per move is not a recommended mode for operating Chess programs: they become very wasteful in terms of CPU usage. I think it was a mistake that it was ever added to WB protocol. It is much better to allow the engine some freedom to distribute time over its moves.

For this reason I have no plans to extend the protocol in this direction.

As this is true for normal play, what about solving testsuites?
Or should the engine then switch into analysis mode?

I could also imagine, after some changes in search, running some fixed time per move games to see, how the search depth is affected.

[hgm]

But would you really need sub-second resolution for that?

[flok]

Fixed maximum time per move is not a recommended mode for operating Chess programs: they become very wasteful in terms of CPU usage. I think it was a mistake that it was ever added to WB protocol. It is much better to allow the engine some freedom to distribute time over its moves.
For this reason I have no plans to extend the protocol in this direction.

Ok but doesn't UCI have such an option too?
It made my tournament program a lot simpler to implement

[hgm]

Indeed, UCI has a 'movetime' command, to specify the time for the next move.

But in fact you can already do something similar in WB protocol: the 'time' command can send the time with centi-second resolution, and the GUI would usually send it before every move the engine must do. That at the beginning of the game the engine receives an 'st N' command only tells it how to interpret the 'time' command (i.e. whether the time if for a single move, a finite number of moves to the end of the session, or for the entire game). The time actually given in the 'st' command is in fact redundant when 'time' commands are sent, because in case of a conflict it is always the latest command that should be obeyed. Similarly, in 'level MPS TC INC' the TC is redundant, as the 'time' commands overrule it. It can only be used as a sort of preview of the engine for how much extra time it can expect at the start of the next session, and thus if it is smart to save some. (E.g. if you have 1 min left for the last move of a 40-move session, it would be smart to use it all for that move if you play 40 moves / 2 hours (as it is already below average), but it would be stupid to use it all when you are playing 40 moves/min (and just came out of book after 39 moves). In the latter case it would be more sensible to consider it 41 moves in 2 min, in which case spending half of your time on the first move would be far from optimal.)