Timing out on threefold repetition draw

[dede1751]

Engine lost on time after 50+ seconds on the last move, which would have been a repetition. https://lichess.org/VwvkZrLWm0mj

[tissatussa]

time management also seems a problem with some other engines .. i found Crabby, rating about 2100, which is a Rust engine too .. its creator had same troubles : https://github.com/Johnson-A/Crabby/issues/5 .. i don't know how to solve them, programmatically, esp. when time increment is involved .. maybe other coders can give you tips or even some code .. good luck solving this.

[dede1751]

Currently very short on time, the strange thing is that this was a one off and Carp seems to normally handle drawing by repetition just fine. Since carp detects draws after just one repetition, I think I'm also going to default to simply repeating the move history without searching when I have reached the same position twice, since the engine has already decided there's nothing better than a draw anyways. This should help prune out possible bugs. Interestingly, Carp seems to be having the opposite problem regarding time management, as it's currently using far too little. Should be a simple tweak to a few constants.

[tissatussa]

anyway, is Carp able to abort the search and give its 'best move' upto that moment ? Can this be any time or after some tree branch is finished ? Some simple engines use just a fixed time for every move, according to the wtime / btime & winc / binc settings, other engines use a simple rule-of-thumb function for time management : at last the moves will be made quicker and quicker .. sophisticated engines seem to know if a position needs more time, maybe because several candidate moves have almost equal eval ..

[tissatussa]

another thing concerning time management : Carp does not reach high search depth like many other engines .. it also does a few thousand nodes compared to millions of other engines .. i'm not a programmer of any engine, just a user, and i don't know how to code such, even in Rust (i do mainly Python and JS) .. is it all about the kind of pruning ? Are C-programs much faster anyway ? Efficient calculation times also depend on these things, isn't it ?

[dede1751]

The amount of nodes is actually reported in KNodes, hence it seems much smaller than it actually is, since during testing it seemed that Arena GUI expected that kind of measure. Actual nps should be 1000x what is reported by the info. Will change this since it seems like it should just be the normal node count. Considering the similarities Carp has with other C engines, the Rust performance is definitely comparable, if not better actually (just through pure perft/time to depth).

Regarding time management, any search that is not completed is technically unusable as a reliable value, as far as I know. When receiving standard wtime/btime time controls without movestogo, carp simply divides this amount by a standard amount of 40 moves and has that amount of time to find the best move. Once a move time is decided, Carp will not change it: I believe that, to get a behavior such as the one you describe, more sophisticated engines will update their move time during the search phase depending on iterative deepening results. The way I do it will definitely waste time on simple moves and not spend enough on complex ones, but it still adapt throughout the game since 1/40th of the total time on the first move is a lot more than 1/40th on the 30th move.

[dede1751]

I've done some testing and could not reproduce this locally. Considering Carp has had no trouble drawing other games by repetition, with this game being the only exception, and keeping in mind that I experienced connection issues while testing, I'm going to conclude my computer disconnected and could not reply with a move. Hopefully this does not come back to bite me in the future.

On a side note, this helped me spot a possible bug where I wasn't considering how null moves leave a "hole" in the position history, which turned out to be a very simple fix.

[tissatussa]

..Actual nps should be 1000x what is reported by the info..

OK, that's clear.

..any search that is not completed is technically unusable as a reliable value, as far as I know..

seems logical .. and when a search is completed upto a certain depth, do you calculate if remaining time will be enough to search a next depth ? I guess so ..

..carp simply divides this amount by a standard amount of 40 moves..

now i remember a rule-of-thumb i once read : that coder used 1/30 in the same manner. If such is an approximation, then it might be useful to you ?

..this helped me spot a possible bug..

nice ! I know how it feels :)

[dede1751]

For now, I'm trying 1/35, but maybe I'll move to 1/30 if it's still not using enough time.

The way timing works is the following:

• Calculate how much time we have for the move based on the uci command (basically, wtime/movestogo + winc or wtime/35 + winc without movestogo).
• At every iterative deepening loop we have a "start" time check: this requires we have at least half the time allocated to searching the move remaining, since generally each iteration takes more time than all the previous iterations combined.
• Every 2048 nodes in our search, we also have another time check which simply checks the current time and sees if we have exceeded the allocated time.

[tissatussa]

that's all clear but the 3rd point :

Every 2048 nodes in our search, we also have another time check which simply checks the current time and sees if we have exceeded the allocated time.

but then the concerning depth is completely finished ? Because you stated

..any search that is not completed is technically unusable as a reliable value..

overall, i can only imagine how max times can influence "best moves" in a game ..

[dede1751]

Yes, if the time check during the search exceeds the allocated time, the search is truncated and its results ignored. This is were further improvements could be made in estimating the amount of time it would take to complete the search and then potentially extend the clock if there's very little left to do. This could for example be implemented at the root node: say if you have only a few root moves to check but are expecting to time out during one of them, simply add more time to the clock by assuming they will take roughly the same as the prior subtrees to search (which, assuming good move ordering and considering for the last moves the bounds will be much tighter, should be a fairly conservative guess)

[tissatussa]

thanks, it's nice to know more.

we can close this Issue now, i have other questions and suggestions for which i will create other Issues .. i love to think and discuss about chess and engines like this, you seem to be inspired building Carp and make it better .. do you play chess yourself ? I'm a club player about 1850 rating.

[dede1751]

I love playing chess, but I've never dedicated much time to playing it seriously. I'm only around 1200 chess.com, most likely closer to 14/1500 if I actually played often, considering my performance over the board against higher rated/club players