Stockfish time management

[Peter Berger]

Stockfish time management is clearly not optimal when it has to play a game from a balanced starting position.
Please have a look at the following game as a striking example/evidence - I have witnessed quite a few similar games ( so this behaviour and game isn't unsual at all) - and everyone will see the same on his computers if he/she tries.
For its first move Stockfish uses about one quarter of its time.
By move 7 it has used more than half of its time.
At move 11 it has used close to 75% of its thinking time.
I strongly suspect this is an artefact of testing with unbalanced opening positions. In unbalanced positions it looks logical to invest a lot of time early on to make good use of the imbalance.
But in balanced positions this is clearly a waste of time - there simply isn't enough difference in evaluation between different moves to make this investment worthwhile.
I don't have the necessary hardware to prove this - but it seems extremely logical that a Stockfish that saves more time for the moves after move 10 has to be stronger. It is also extremely boring to wait for it burning all this time to no avail early on as a human spectator (which would be my personal motivation for this post ) .
[Event "Lang 120min+10sek"]
[Site "Berlin"]
[Date "2024.07.31"]
[Round "?"]
[White "Stockfish dev-20240728-2343f71"]
[Black "Crafty 25.6"]
[Result "1-0"]
[ECO "B48"]
[PlyCount "145"]
[TimeControl "7200+10"]

{4096MB, DESKTOP-8OCGGEO} 1. e4 {[%eval 12,49] [%wdl 44,936,20] [%emt 0:28:22]} c5 {[%emt 0:00:09]} 2. Nf3 {[%eval 31,42] [%wdl 83,907,10] [%emt 0:04:53]} e6 {[%emt 0:00:06] (Sc6)} 3. d4 {[%eval 42,40] [%wdl 118,875,7] [%emt 0:03:35]} cxd4 {[%emt 0:00:06]} 4. Nxd4 {[%eval 46,37] [%wdl 128,867,5] [%emt 0:02:29]} Nc6 {[%emt 0:00:07] (a6)} 5. Nc3 {[%eval 41,42] [%wdl 102,892,6] [%emt 0:02:56]} Qc7 {[%emt 0:00:06]} 6. Be3 {[%eval 41,46] [%wdl 104,891,5] [%emt 0:13:51]} Nf6 {[%emt 0:00:08] (a6)} 7. f4 {[%eval 57,38] [%wdl 170,827,3] [%emt 0:04:00]} Bb4 {[%emt 0:00:07]} 8. Ndb5 {[%eval 59,36] [%wdl 180,817,3] [%emt 0:02:06]} Qa5 {[%emt 0:00:08]} 9. e5 {[%eval 51,36] [%wdl 142,854,4] [%emt 0:02:33]} Nd5 {[%emt 0:00:07]} 10. Bd2 {[%eval 41,37] [%wdl 103,891,6] [%emt 0:02:52]} Nxc3 {[%emt 0:00:09]} 11. Nxc3 {[%eval 44,48] [%wdl 97,900,3] [%emt 0:19:27]} d5 {[%emt 0:00:08]} 12. exd6 {[%eval 39,39] [%wdl 69,928,3] [%emt 0:01:11]} Bxd6 {[%emt 0:08:20] (0-0)} 13. a3 {[%eval 42,41] [%wdl 73,925,2] [%emt 0:08:19]} Qb6 {[%emt 0:03:45] (0-0)} 14. Qg4 {[%eval 55,37] [%wdl 123,876,1] [%emt 0:01:41]} Qxb2 {[%emt 0:03:43]} 15. Rb1 {[%eval 77,39] [%wdl 262,738,0] [%emt 0:00:08]} Qxc2 {[%emt 0:02:38]} 16. Qxg7 {[%eval 45,38] [%wdl 74,925,1] [%emt 0:00:40]} Rf8 {[%emt 0:01:49]} 17. Qg3 {[%eval 47,39] [%wdl 78,921,1] [%emt 0:00:51]} Qg6 {[%emt 0:02:46]} 18. Bd3 {[%eval 55,38] [%wdl 107,892,1] [%emt 0:00:04]} f5 {[%emt 0:02:43] (Dxg3+)} 19. Nb5 {[%eval 83,38] [%wdl 313,687,0] [%emt 0:01:18]} Bb8 {[%emt 0:00:57]} 20. Be2 {[%eval 80,39] [%wdl 286,714,0] [%emt 0:01:14]} a6 {[%emt 0:02:24] (Kf7)} 21. Qh3 {[%eval 70,40] [%wdl 198,802,0] [%emt 0:01:34]} Qg7 {[%emt 0:00:36]} 22. Bh5+ {[%eval 74,42] [%wdl 226,774,0] [%emt 0:00:47]} Ke7 {[%emt 0:01:22] (Kd8)} 23. Nc3 {[%eval 122,32] [%wdl 735,265,0] [%emt 0:01:21]} Rd8 {[%emt 0:01:07]} 24. Ne2 {[%eval 108,31] [%wdl 595,405,0] [%emt 0:00:02]} Qh6 {[%emt 0:01:57]} 25. Rf1 {[%eval 100,33] [%wdl 500,500,0] [%emt 0:01:09]} Kf8 {[%emt 0:04:25]} 26. Bc3 {[%eval 145,38] [%wdl 892,108,0] [%emt 0:01:47]} b5 {[%emt 0:14:16] (Se7)} 27. g4 {[%eval 226,30] [%wdl 997,3,0] [%emt 0:00:48]} e5 {[%emt 0:01:36]} 28. g5 {[%eval 239,33] [%wdl 998,2,0] [%emt 0:00:01]} Qe6 {[%emt 0:01:38] (Dd6)} 29. g6 {[%eval 267,34] [%wdl 1000,0,0] [%emt 0:02:22]} Ra7 {[%emt 0:01:41]} 30. Bf3 {[%eval 274,33] [%wdl 1000,0,0] [%emt 0:00:01]} Kg8 {[%emt 0:01:59]} 31. Qh4 {[%eval 282,35] [%wdl 1000,0,0] [%emt 0:00:01]} hxg6 {[%emt 0:01:31]} 32. Bxc6 {[%eval 283,31] [%wdl 1000,0,0] [%emt 0:00:02]} Rf8 {[%emt 0:06:55]} 33. Bf3 {[%eval 293,36] [%wdl 1000,0,0] [%emt 0:00:01]} Rh7 {[%emt 0:01:47] (Lb7)} 34. Qg3 {[%eval 302,29] [%wdl 1000,0,0] [%emt 0:01:00]} exf4 {[%emt 0:01:44] (Lb7)} 35. Qg2 {[%eval 322,27] [%wdl 1000,0,0] [%emt 0:00:47]} Rd7 {[%emt 0:00:30]} 36. Rg1 {[%eval 343,27] [%wdl 1000,0,0] [%emt 0:00:22]} Kf7 {[%emt 0:00:37]} 37. Kf1 {[%eval 346,27] [%wdl 1000,0,0] [%emt 0:00:18]} Rg8 {[%emt 0:01:14] (Tfd8)} 38. Re1 {[%eval 356,30] [%wdl 1000,0,0] [%emt 0:01:03]} a5 {[%emt 0:00:08] (Le5)} 39. Qh3 {[%eval 413,32] [%wdl 1000,0,0] [%emt 0:00:50]} Be5 {[%emt 0:01:20]} 40. Qh7+ {[%eval 472,35] [%wdl 1000,0,0] [%emt 0:00:01]} Rg7 {[%emt 0:01:23]} 41. Qh8 {[%eval 482,32] [%wdl 1000,0,0] [%emt 0:00:01]} Rd3 {[%emt 0:01:13]} 42. Nd4 {[%eval 501,34] [%wdl 1000,0,0] [%emt 0:00:01]} Rg8 {[%emt 0:01:19] (Dc4)} 43. Qh7+ {[%eval 510,33] [%wdl 1000,0,0] [%emt 0:00:49]} Rg7 {[%emt 0:00:17]} 44. Nxe6 {[%eval 530,35] [%wdl 1000,0,0] [%emt 0:01:05]} Rxf3+ {[%emt 0:00:08]} 45. Kg2 {[%eval 552,32] [%wdl 1000,0,0] [%emt 0:00:49]} Rxh7 {[%emt 0:00:06]} 46. Ng5+ {[%eval 564,30] [%wdl 1000,0,0] [%emt 0:00:38]} Kg8 {[%emt 0:00:07]} 47. Nxf3 {[%eval 572,33] [%wdl 1000,0,0] [%emt 0:00:34]} Bxc3 {[%emt 0:02:09]} 48. Re8+ {[%eval 572,39] [%wdl 1000,0,0] [%emt 0:00:01]} Kg7 {[%emt 0:00:54]} 49. Rxc8 {[%eval 586,34] [%wdl 1000,0,0] [%emt 0:00:01]} b4 {[%emt 0:00:40]} 50. Kh1 {[%eval 595,33] [%wdl 1000,0,0] [%emt 0:00:06]} Rh3 {[%emt 0:01:47] (Th8)} 51. Rc7+ {[%eval 659,35] [%wdl 1000,0,0] [%emt 0:00:47]} Kf6 {[%emt 0:00:06]} 52. Kg2 {[%eval 700,29] [%wdl 1000,0,0] [%emt 0:00:31]} Rh8 {[%emt 0:01:01]} 53. axb4 {[%eval 735,33] [%wdl 1000,0,0] [%emt 0:00:01]} axb4 {[%emt 0:00:40] (Lxb4)} 54. Rd1 {[%eval 938,35] [%wdl 1000,0,0] [%emt 0:00:43]} Re8 {[%emt 0:01:32] (Ke6)} 55. h4 {[%eval 19960,59] [%wdl 1000,0,0] [%emt 0:00:51]} Re2+ {[%emt 0:01:17]} 56. Kf1 {[%eval 19968,56] [%wdl 1000,0,0] [%emt 0:00:01]} Re7 {[%emt 0:00:48] (Te3)} 57. Rd6+ {[%eval 32718,59] [%wdl 1000,0,0] [%emt 0:00:36]} Re6 {[%emt 0:00:06]} 58. Rdd7 {[%eval 32724,56] [%wdl 1000,0,0] [%emt 0:01:12]} Ra6 {[%emt 0:00:09]} 59. Ng5 {[%eval 32730,59] [%wdl 1000,0,0] [%emt 0:00:36]} f3 {[%emt 0:00:07]} 60. Kf2 {[%eval 32732,57] [%wdl 1000,0,0] [%emt 0:01:01]} f4 {[%emt 0:00:35] (Le1+)} 61. Kxf3 {[%eval 32736,61] [%wdl 1000,0,0] [%emt 0:00:40]} Ra5 {[%emt 0:00:31]} 62. Kxf4 {[%eval 32738,61] [%wdl 1000,0,0] [%emt 0:00:06]} Rf5+ {[%emt 0:00:18]} 63. Kg4 {[%eval 32742,69] [%wdl 1000,0,0] [%emt 0:00:19]} Rxg5+ {[%emt 0:00:07]} 64. hxg5+ {[%eval 32744,71] [%wdl 1000,0,0] [%emt 0:00:28]} Ke5 {[%emt 0:00:44] (Ke6)} 65. Rb7 {[%eval 32748,80] [%wdl 1000,0,0] [%emt 0:00:35]} Ke6 {[%emt 0:00:52] (Ke4)} 66. Rd1 {[%eval 32750,81] [%wdl 1000,0,0] [%emt 0:00:29]} Bb2 {[%emt 0:00:07] (b3)} 67. Rxb4 {[%eval 32752,82] [%wdl 1000,0,0] [%emt 0:00:24]} Ba3 {[%emt 0:00:43]} 68. Re4+ {[%eval 32754,89] [%wdl 1000,0,0] [%emt 0:00:01]} Kf7 {[%emt 0:00:05]} 69. Rd7+ {[%eval 32756,126] [%wdl 1000,0,0] [%emt 0:00:17]} Kf8 {[%emt 0:00:06]} 70. Ra4 {[%eval 32758,206] [%wdl 1000,0,0] [%emt 0:00:14]} Be7 {[%emt 0:00:30] (Ke8)} 71. Raa7 {[%eval 32760,231] [%wdl 1000,0,0] [%emt 0:00:20]} Bxg5 {[%emt 0:00:27] (Kf7)} 72. Ra8+ {[%eval 32764,245] [%wdl 1000,0,0] [%emt 0:00:01]} Bd8 {[%emt 0:00:06]} 73. Raxd8# {[%eval 32766,245] [%wdl 1000,0,0] [%emt 0:00:00]} 1-0

[JacquesRW]

Stockfish time management is clearly not optimal when it has to play a game from a balanced starting position.
Please have a look at the following game as a striking example/evidence - I have witnessed quite a few similar games ( so this behaviour and game isn't unsual at all) - and everyone will see the same on his computers if he/she tries.
For its first move Stockfish uses about one quarter of its time.
By move 7 it has used more than half of its time.
At move 11 it has used close to 75% of its thinking time.
I strongly suspect this is an artefact of testing with unbalanced opening positions. In unbalanced positions it looks logical to invest a lot of time early on to make good use of the imbalance.
But in balanced positions this is clearly a waste of time - there simply isn't enough difference in evaluation between different moves to make this investment worthwhile.
I don't have the necessary hardware to prove this - but it seems extremely logical that a Stockfish that saves more time for the moves after move 10 has to be stronger. It is also extremely boring to wait for it burning all this time to no avail early on as a human spectator (which would be my personal motivation for this post ) .

If you’re so convinced then submit a patch on fishtest that uses a balanced book, it will verify or reject your hypothesis quickly enough. Making a post on a forum that no one uses for actual dev anymore with dubious evidence is pointless - your (heavily biased selection of) anecdotal games are not sufficient.

[chesskobra]

I have made similar observations as OP. Everybody is not into submitting patches to fishtest or running 1000s of games to validate their observations, but the observations are still worth discussing. SF developers or others can ignore the topic if they think it is dubious or whatever.

In fact just recently I had been thinking of reporting similar observations (not just about Stockfish) from my tests. If you set a time control like 40 moves per 5 minutes, some engines get very close to time control, having played only 30-35 moves, and then they have to play very fast and can end up blundering. I observed this multiple times. One solution is to set 8 moves per minute instead of 40 moves per 5 minutes. Then the problem is at least partially overcome it seems. I don't know if the cause is that engines are tested with unbalanced positions. But I think some engines, especially the ones that are already quite strong, would make significant progress simply by improving their time management.

[JacquesRW]

I have made similar observations as OP. Everybody is not into submitting patches to fishtest or running 1000s of games to validate their observations, but the observations are still worth discussing. SF developers or others can ignore the topic if they think it is dubious or whatever.

In fact just recently I had been thinking of reporting similar observations (not just about Stockfish) from my tests. If you set a time control like 40 moves per 5 minutes, some engines get very close to time control, having played only 30-35 moves, and then they have to play very fast and can end up blundering. I observed this multiple times. One solution is to set 8 moves per minute instead of 40 moves per 5 minutes. Then the problem is at least partially overcome it seems. I don't know if the cause is that engines are tested with unbalanced positions. But I think some engines, especially the ones that are already quite strong, would make significant progress simply by improving their time management.

That’s could be due to engines no longer caring about cyclic TCs. The second CCRL stopped using them, they lost most relevance in the eyes of devs (and some engines now explicitly do not support such TCs now).

[Viz]

would make significant progress simply by improving their time management.

I also think that they can do it by simply improving search, move ordering and eval.
Idk why no of their devs ever thought of this simple tricks.

[Eelco de Groot]

As a user you can increase I think Move Overhead to something like 1 minute for TCEC order of timemagement games. I don't know exactly what is "7200 + 10" Peter uses in this game but assume everything at these timecontrols needs more of a reserve. I think Stockfish has some other time controls options too, some UCI for end users, but Move Overhead is known in other programs too? What is the purpose of achieving statistical significance on Fishtest for every patch that has to be tested at these time controls because it is likely time control dependant. It is not going to be allowed, waste of resources or am I wrong about that. So no point pointing to Fishtest. It is not everything and should be used more conservatively anyway. Like AI and cryptocurrency, Facebook, blockchaining and numerical simulations of atomic bombs and such. Just shut it down

[Peter Berger]

As a user you can increase I think Move Overhead to something like 1 minute for TCEC order of timemagement games. I don't know exactly what is "7200 + 10" Peter uses in this game but assume everything at these timecontrols needs more of a reserve.

Time control is simply game in 2 hours with 10 secs increment/move. There is also no need for some fancy additional options or reserve, Stockfish is using exactly as much time for each move as it wants to, this is no issue (these are manual games run on two computers).

[JacquesRW]

What is the purpose of achieving statistical significance on Fishtest for every patch that has to be tested at these time controls because it is likely time control dependant. It is not going to be allowed, waste of resources or am I wrong about that.

OP made a blanket claim about TM in balanced positions, it does not need to be tested at the same extreme LTC on fishtest to determine the validity of the claim in general. Perhaps it will be disallowed, but I don’t see why, if you could make an argument that such a patch is indeed different on balanced positions vs unbalanced.

So no point pointing to Fishtest. It is not everything and should be used more conservatively anyway.

Any functional patch for TM would be required to pass on Fishtest, no? Do you think it should be used more conservatively for any reason other than hardware constraints?

[chesskobra]

That’s could be due to engines no longer caring about cyclic TCs. The second CCRL stopped using them, they lost most relevance in the eyes of devs (and some engines now explicitly do not support such TCs now).

Isn't CCRL 40/15 still using cyclic time controls, as mentioned here https://www.computerchess.org.uk/ccrl/4040/about.html?

[JacquesRW]

That’s could be due to engines no longer caring about cyclic TCs. The second CCRL stopped using them, they lost most relevance in the eyes of devs (and some engines now explicitly do not support such TCs now).

Isn't CCRL 40/15 still using cyclic time controls, as mentioned here https://www.computerchess.org.uk/ccrl/4040/about.html?

No, that information is out of date. CCRL 40/15 is now played at 12mins + 8secs (it has been suggested that the list should be renamed to CCRL Rapid).