Stockfish time management

[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?

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).

Thanks for the info. I also noticed that the pgn file there does not have TimeControl tags.

Even with incremental time control, what I expect to observe with many engines (based on very little data at slightly faster time controls) is that the engines would run out of time and play a large part of the game on increment. Let us say a game lasts 90 moves. Then if the engine used all its available time, it would use 24 minutes for 90 moves, which is 16 seconds per move. So if an engine plays a large part of the game, say the last 40-50 moves, only on the increment of 8 seconds per move, it is quite suboptimal.

[Ciekce]

it is quite suboptimal.

source?

[chesskobra]

it is quite suboptimal.

source?

Read the full sentence. I said "If the engine does xyz, it is quite suboptimal". You want source for what?

[Ciekce]

Read the full sentence. I said "If the engine does xyz, it is quite suboptimal". You want source for what?

I want a source for that time management behaviour being suboptimal. "I feel like it might be" does not cut it.

As usual, this is idle speculation that what SF does might be bad oh no!!! - and yet none of you are ever willing to make fishtest accounts and test the changes you want to see.

[Peter Berger]

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.

Thanks for reading my post carefully.
Actually I probably claimed even more. I assumed the current time management system must have tested positively against something more straightforward in the past, and when you run enough games. I tried to make up a potential reason on the fly with the "balance theory" ( guesswork and a little bit of logic). This may even be true, but of course this would be a second test to be done only if needed.
I don't see why the long time control in my games should make any difference in principle, so I would only ask for special tests if for some reason a similar behaviour doesn't show up at very fast time controls (and I have no idea why it shouldn't)
To answer your question: why don't I code it then and put it up for test at fishtest? The reason is simple enough: I am no programmer, so I wouldn't be able to implement things. I haven't even had a look at the time management code in Stockfish yet, assuming it is probably too complicated for me to understand.
Being no programmer doesn't mean I can't think though.
There is no way that it is optimal behaviour to use a quarter of your thinking time for the first move using the classical starting position. (Or to use an insane amount of time for the first 10 moves for that matter). The burden of proof that this is a good idea would be on someone who disagrees IMHO.
Why don't I run a few thousand games at least to prove that it is a better idea to use only one minute for the first move in my exact experimental setup? Because someone else can do a much more meaningful test with close to zero effort while it would demand an insane amount of effort from me.
On the other hand people who do have the necessary skills may have never witnessed such a Stockfish game with a time control of two hours with 10 seconds/increment, so while "anecdotal games" are not sufficient ( and I agree) , it may still be useful to know about them.
Peter

[chesskobra]

Read the full sentence. I said "If the engine does xyz, it is quite suboptimal". You want source for what?

I want a source for that time management behaviour being suboptimal. "I feel like it might be" does not cut it.

As usual, this is idle speculation that what SF does might be bad oh no!!! - and yet none of you are ever willing to make fishtest accounts and test the changes you want to see.

First, I didn't say anything about Stockfish in particular. I am not going to do fishtest or run 100s of games. I run games between engines for watching them, I rarely try to run any statistical tests, although I am currently doing some tests systematically to compare different Lc0 nets (and SF 13 compiled with a maia net) because I could not find the data. But I am not making things up. I have observed these problems in my limited matches, which is why for my personal matches I have switched to a more uniform time control like 8 or 6 or fewer moves per minute. I have seen time management issues even on TCEC. I don't run these matches at 12+8, but faster TCs (with increment), which is why the speculation that similar thing might happen at 12+8.

[Ras]

So if an engine plays a large part of the game, say the last 40-50 moves, only on the increment of 8 seconds per move, it is quite suboptimal.

No, it's not, quite the other way around. If the game doesn't last that long, it means that available time went wasted. Time that could have been used to find better moves early on for getting a better base position, ideally an already winning one.

[Ciekce]

First, I didn't say anything about Stockfish in particular. I am not going to do fishtest or run 100s of games. I run games between engines for watching them, I rarely try to run any statistical tests, although I am currently doing some tests systematically to compare different Lc0 nets (and SF 13 compiled with a maia net) because I could not find the data. But I am not making things up. I have observed these problems in my limited matches, which is why for my personal matches I have switched to a more uniform time control like 8 or 6 or fewer moves per minute. I have seen time management issues even on TCEC. I don't run these matches at 12+8, but faster TCs (with increment), which is why the speculation that similar thing might happen at 12+8.

You misunderstand me - I am not actually asking you to verify the problem, I am telling you that the problem you think you are observing does not exist. Again, if you think your intuition is worth anything, then try out your ideas in an actual engine, otherwise why bother complaining? Tip: engines work the way they do for a reason. Switching to some weird cyclic TC is *weakening* the engines by not allowing them to manage their time properly, whether you like it or not.

[chesskobra]

OK, so I would like to ask what are the ideal time controls for Stockfish and Lc0 (for fast and slow games, with Lc0 used with small nets on CPU), and if it is hardware dependent, how should I decide. Is it like increment = a certain proportion of initial time? Also, if I am not using a tablebase, which would mean in the endgame the engines would need more time to make good decisions, how should I adjust the TC? Are there any documented guidelines as to how to set TC?

[mosfel24]

I just wanted to share my two cents on this matter.

I do not like to see Stockfish burning all its time on simple opening moves such as "e4". I believe that to create the most optimal time management, we should look at average grandmaster thinking times in a chess game. After all, this is how humans have been doing it for hundreds of years more or less. While SF, Fishtest, lookalikes, etc. have only existed for a moment in time. It is like the entire human civilization obsessed with talking about themselves all the time while other forms of life have existed for billions of years.



I have hardcoded this graph, taken from CPW, into all of my engines. Of course it is scaled to the time control my engine is playing at, and it works perfectly. When I watch the games, it seems so human-like. I have also expanded this to cyclic time controls with my good judgement.