On time management

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Ras
Posts: 2487
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

On time management

Post by Ras »

One of the most rewarding issues for serious games is time management. At the 2016 dedicated chess computer tournament in Germany, the CT800 suffered from poor time management - for the game-in mode, it only used 1/3 of its total time at move 40. So I had to improve that, which will be part of the upcoming V1.02 release.

There are some time-saving shortcuts implemented:

- if there are opening book moves available, select one of them.
- if there is only one legal move, just do it.
- if the CT800 can mate, just do it.
- if there is only one move that prevents being mated in the next move, just do it.
- if being mated in the next move cannot be prevented, do any legal move.
- if there is an "easy move" (see http://www.talkchess.com/forum/viewtopi ... ht=#692554 ), do it.
- using iterative deepening, if the time budget allocated for the current move has already been used up to more than 55%, then don't start another depth iteration.

So far so obvious. The interesting thing now is the time allocation schedule, and the general approach is to divide the game into "move decades". BTW., this isn't NG-Play code anymore, this is CT800 only. I'll outline this for the game-in mode; for tournament modes, it is similar.

Each move decade gets a percentage of the remaining time, and each move within that decade gets 1/10th of that as allocated time. Move decade 1-10: 24%, move decade 11-20: 26%, move decade 21-30: 21%, move decade 31-40: 15%.

You will notice that this is 86% of the total time. Due to the time saving features mentioned above, the real time usage by move 40 is around 2/3 of the total time, which is the actual target. Compared to V1.01, this means the CT800 is using twice as much time until move 40, which corresponds to around +50 ELO for this important game phase.

Right after move 40, there is a rebasing point. This means the following percentages refer to the actually remaining time (without possible Fischer per-move add-up).

Moves 41-50: 30%, move 51-60: 25%. Another rebasing point right after move 60. Move 61-70: 32%, move 71-80: 28%, move 81-90: 18%. Another rebasing point right after move 90. Move 91-100: 32%, move 101-110: 24%, move 111-120: 22%. Then the last rebasing happens - each following move gets 1/80th of the remaining time since 200 moves is the maximum the CT800 can track. More than 120 moves don't really happen anyway, and then only as shuffling around until draw-by-50.

Tournament modes work in a similar way with an additional rebasing point after move 20 and an effective target of around 85% at move 40.

I know there are simpler ways, but quite a lot of them involve the logic "if the eval is dropping, then invest more time to find a defence". My approach is to allocate more time early on to prevent this scenario from happening. If that happens, it will mostly be too late anyway.

In practice, this allocation schedule seems to work quite well.
Michael Sherwin
Posts: 3196
Joined: Fri May 26, 2006 3:00 am
Location: WY, USA
Full name: Michael Sherwin

Re: On time management

Post by Michael Sherwin »

One thing you can try is limiting search depth to no more than one or two ply deeper than the previous depth. The engine would be searching two or three ply deeper than what the last move it played. ... It seems to be doing pretty good in my engine, RomiChess. Saves a lot of time on some searches leaving more time for future searches.
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
User avatar
hgm
Posts: 27790
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: On time management

Post by hgm »

It depends a lot on TC mode. With classical (moves-per-session) TC there is little to gain.

In sudden-death or incremental TC, I make anestiate of the number of moves the game would still last (e.g. based on total material and root score). Then divide the remaining time by that number of moves, and multiply by 1.5 or so (because early moves are more important than late moves). That gives you a target time. Then I di the usual things of not starting a new iteration if already more than (say) 60% of the target time has expired, etc.
Ras
Posts: 2487
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: On time management

Post by Ras »

Michael Sherwin wrote:One thing you can try is limiting search depth to no more than one or two ply deeper than the previous depth.
Which seems to pre-pone the problem of how much time to allocate?
Ras
Posts: 2487
Joined: Tue Aug 30, 2016 8:19 pm
Full name: Rasmus Althoff

Re: On time management

Post by Ras »

hgm wrote:It depends a lot on TC mode. With classical (moves-per-session) TC there is little to gain.
That is the tournament mode, correct. But even there, investing more time early on is what grandmasters are doing. Of course, this is most rewarding in time-per-game mode.
Then divide the remaining time by that number of moves, and multiply by 1.5 or so (because early moves are more important than late moves)
Also a possibility. It seems that the Mephisto MM5 is doing something like this, and the typical result is that it has used up 50% of the time (for game-in) after move 40. That's a bit too little. Then at around move 60, the times get equal, and the MM5 then is lacking time in the endgame.
User avatar
hgm
Posts: 27790
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: On time management

Post by hgm »

Ras wrote:That is the tournament mode, correct. But even there, investing more time early on is what grandmasters are doing. Of course, this is most rewarding in time-per-game mode.
Sure, that is what the factor 1.5 takes care of. For TC where you can get close to forfeiting (such as classical and incremental with low base time) it pays to keep some spare time, e.g. 2x target time, so that in case of trouble in the last move of your session you can still use 3x target time. So I calculate the 'cold-turkey timeout' as

3*targetTime

where the latter is

timeLeft/(movesLeft + 2)