Move overhead

[Gabor Szots]

This is a parameter of many engines, to be set in milliseconds. Please enlighten me, is this related to each move or the whole game.

[Eelco de Groot]

Hello Gabor,

Dio just yesterday answered the same question for me in the CS Tal and Rebel 16.1 thread in ProDeo forum.

[RubiChess]

Well, this answer is only particularly true.
It depends what the engine does with this move overhead parameter.
RubiChess more or less takes moveoverhead only to avoid time forfeit in the next move.
But Stockfish assumes that _every_ move needs additional moveoverhead time for GUI communication, so it reduces the time to spend on the move with movestogo * moveoverhead and movestogo is 50 if not given explicitely in the go command.
Look at https://github.com/official-stockfish/S ... an.cpp#L65 and following lines.

https://github.com/ShailChoksi/lichess-bot/issues/562 shows that a big move overhead (900ms) in combination with a short time control (30s) leads to very bad play in Stockfish, at least in sudden death without increment time control.

Regards, Andreas

[Modern Times]

Must also depend on the type of time control too for some engines. On a repeating time control, then if not per move it would apply to the end of each block.

[Gabor Szots]

RubiChess more or less takes moveoverhead only to avoid time forfeit in the next move.

Does that mean that at each move it assumes it has (Remaining time on the clock)-(Move Overhead) time to think?

That would cripple its strength considerably because in a 60-move game with 1s move overhead it will lose a whole minute thinking time.

[RubiChess]

RubiChess more or less takes moveoverhead only to avoid time forfeit in the next move.

Does that mean that at each move it assumes it has (Remaining time on the clock)-(Move Overhead) time to think?

That would cripple its strength considerably because in a 60-move game with 1s move overhead it will lose a whole minute thinking time.

Of course not. It is far more complicated.
Rubi uses two possible points of "time to stop".
First one is considered when an iteration is finished and search depth would increase. This usually leaves quite a lot time remaining for the next moves.
Second one is taken when an iteration takes a lot of time an the engine thinks "well, now we REALLY should stop thinking even if this iteration is not finished".
Both points of time take various parameters into account like take more time if score is instable or best move changes a lot and one of these parameters is move overhead which gets important with very few time remaining and basically says: If time forfeit would happen at time x, regardless of score being instable or whatever, latest possible time to play the move is x-moveoverhead. But different from SF, Rubi does not say: I have 40 moves to go until next time control and my moveoverhead is 1s, so I throw away 40s from the time the GUI gives and calculate with the rest.

Regards, Andreas

[Gabor Szots]

Thanks Andreas, very clear explanation.

Regards,
Gabor

[Jouni]

Koivisto is exemplary. It has MoveOverHeadType: PerMove or PerGame. But who needs that? I played Koivisto vs Stockfish default setting at 2s+0,02s no time losses in Cute Chess GUI! Koivisto default 0 ms and SF 10 ms.

[JohnWoe]

MoveOverhead is a very complex mathematical equation.

TimeLeft - MoveOverhead == Maximum time left for move.

Although only CuteChess-cli is able to implement clock properly. PyChess, Xboard all have issues. Haven't tested Banksia much. Maybe it works properly.