Crafty 22.10 time management problem.

[Graham Banks]

When using an x moves in y minutes repeating time control, after the first time control Crafty very quickly uses up most of its allotted time, meaning it has to play blitz for the majority of the second time control.

[Graham Banks]

The latest version of BBChess also seems to have a problem after the first time control is reached.

[Matthias Gemuh]

Hi Graham,
if the Crafty and BBChess games were played under ChessGUI, send me the debugs
Best,
Matthias.

[Graham Banks]

Hi Graham,
if the Crafty and BBChess games were played under ChessGUI, send me the debugs
Best,
Matthias.

Hi Matthias,

This problem occurs under Fritz, Arena, Shredder and ChessGUI.

Cheers, Graham.

[Matthias Gemuh]

Hi Graham,
if the Crafty and BBChess games were played under ChessGUI, send me the debugs
Best,
Matthias.

Hi Matthias,

This problem occurs under Fritz, Arena, Shredder and ChessGUI.

Cheers, Graham.

Then I need not care too much.

Matthias.

[Graham Banks]

Hi Graham,
if the Crafty and BBChess games were played under ChessGUI, send me the debugs
Best,
Matthias.

Hi Matthias,

This problem occurs under Fritz, Arena, Shredder and ChessGUI.

Cheers, Graham.

Then I need not care too much.

Matthias.

Indeed. I sent you some debug files anyway, just in case they tell you anything useful.

Cheers, Graham.

[bob]

When using an x moves in y minutes repeating time control, after the first time control Crafty very quickly uses up most of its allotted time, meaning it has to play blitz for the majority of the second time control.

I believe this is a known issue, dealing with a GUI that either plays the opening moves itself, or else from starting at a specific opening position where the first N moves are "stuffed" into Crafty.

If that is what you are doing, 23.0 will solve it I believe. It took a significant rewrite of the timing code to fix this because Crafty did not count moves entered while in "force" mode since it wasn't searching at all.

What happens is, say, you force the first 10 moves so that both programs start from a known opening position. And you are playing 40/40 repeating. The first 10 moves are not counted, so crafty really plays like the first time control is 50/40 because it is not aware that the first 10 moves were even played. That actually makes it play a bit faster than it should. But when the GUI gets to move 40 and says "you now have 40 more minutes on your clock, Crafty thinks "aha, I am 10 moves away from time control, and I have all this extra time built up, so I am going to burn it up... It will often lose on time because of that. It depends on how many moves are "stuffed in" and the overall time control. But it doesn't work. If you start form move 1 normally, it should _never_ have any time control issues, but if you force the first N moves either by starting from a specific opening position, or if the GUI plays the opening itself and then starts Crafty to handle the positions after the GUI has exhausted the book moves, this will break in versions prior to 23.0. I hope to release 23.0 right after the CCT event...

[Graham Banks]

When using an x moves in y minutes repeating time control, after the first time control Crafty very quickly uses up most of its allotted time, meaning it has to play blitz for the majority of the second time control.

I believe this is a known issue, dealing with a GUI that either plays the opening moves itself, or else from starting at a specific opening position where the first N moves are "stuffed" into Crafty.

If that is what you are doing, 23.0 will solve it I believe. It took a significant rewrite of the timing code to fix this because Crafty did not count moves entered while in "force" mode since it wasn't searching at all.

What happens is, say, you force the first 10 moves so that both programs start from a known opening position. And you are playing 40/40 repeating. The first 10 moves are not counted, so crafty really plays like the first time control is 50/40 because it is not aware that the first 10 moves were even played. That actually makes it play a bit faster than it should. But when the GUI gets to move 40 and says "you now have 40 more minutes on your clock, Crafty thinks "aha, I am 10 moves away from time control, and I have all this extra time built up, so I am going to burn it up... It will often lose on time because of that. It depends on how many moves are "stuffed in" and the overall time control. But it doesn't work. If you start form move 1 normally, it should _never_ have any time control issues, but if you force the first N moves either by starting from a specific opening position, or if the GUI plays the opening itself and then starts Crafty to handle the positions after the GUI has exhausted the book moves, this will break in versions prior to 23.0. I hope to release 23.0 right after the CCT event...

Thanks Bob for your explanation. Yes - I am using a neutral book for all engines in my testing. I'm very thankful that you're trying to fix this in Crafty 23.0.
Good luck in CCT.

Regards, Graham.