Komodo time management

[Jesse Gersenson]

"On some GUIs (notibly Little Blitzer) Komodo 9 would time-forfeit over 10% of the games at game/1'"

[Zenmastur]

I want to thank you for your post, although it failed to make clear that you were referring to sudden death games (zero increment). Your post together with complaints from some users about time forfeits in sudden death games caused us to take another look at our time management for sudden death games, and indeed it was way too aggressive. On some GUIs (notibly Little Blitzer) Komodo 9 would time-forfeit over 10% of the games at game/1', which I consider unacceptable. Although on other GUIs it is not this bad, it is clear that Komodo 9 plays too slowly in sudden death games, and this lead to our release today of version 9.01. The reason this happened is that we always test with at least some small increment, and our time management works fine then. Version 9.01 plays sudden death games at about the same speed as Stockfish, although using a very different algorithm, so time usage should no longer be a significant factor in any Komodo 9.01 vs. Stockfish matches sudden death matches. As for the elo gain from version 9 to 9.01 in sudden death games, test results at different levels and different GUIs ranged from plus 2 to plus 18, with an average of about plus 8 elo. Most of the gain is due to (nearly) eliminating time forfeits, although results are slightly plus even without counting the forfeits.

Maybe the Stockfish Team should look at this as well. I was running matches using Little Blitzer and SF Dev and an older version of Komodo both seemed to have a high number of time forfeits due to their very aggressive time usage. I don't recall the exact time controls I was using but it was very fast. I added increments to try to stop this behavior but with Stockfish it seemed to need 0.2" increment to drop significantly. When I have some time I'll try running some tests to pin this behavior down a little more precisely. I thought this was kind of odd at the time but was busy so I didn't investigate it further.

Regards,

Zen

[lkaufman]

How is that possible? If the games it forfeited would on the average have given it half a point, forfeiting 10% would have cost it 35 Elo. If it performs even better than the games it did not forfeit, the gain should even be more than 35 Elo. Was it predominantly forfeiting games it was losing?

Actually, this I a good question, and prompted me to review the data. It seems that when I originally tested it at 1', I ran 16 games on a 16 core machine against Stockfish and got 13% forfeits in a thousand games. But in later tests I ran only 15 games, leaving one core to run the tester and everything else Windows wants to do, and the forfeit percentage dropped a lot. It was also lower on a Haswell machine even without doing this. When I ran 9.01 vs 9.00 directly, I got just 6% time forfeits (for version 9, none for 9.01) and 18 elo gain; at 5' I got 2% forfeits (all for ver. 9) and a 6.3 elo gain. I suppose time forfeits are more common in losing positios, but anyway this data indicates that we solved the forfeit problem with no significant difference in results of the non-forfeited games.

[zamar]

I suppose time forfeits are more common in losing positios, but anyway this data indicates that we solved the forfeit problem with no significant difference in results of the non-forfeited games.

When following SF's games I've seen a pattern that it is much more likely to end up in a serious time trouble when it has a difficult position with somewhat negative eval.

Of course it all depends on time allocation algorithm, but I wouldn't be surprised if the same pattern applied to Komodo as well...