-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TC 40/15 with low depth moves #4000
Comments
I observed this at 40/4 repeating time control at chess960 as well. It is a legacy time control for sure, I don't think anyone would choose it starting afresh today. But it should still be looked at. |
the problem is that with low time left (comparable to moveoverhead), and just one move we will essentially not search, so I've scheduled a test that would fix this: https://tests.stockfishchess.org/tests/view/6274e951e713302ff8f709c7 |
Maybe you find this useful...
|
between SF 14 an SF14.1 there is |
Attached is a debug file that might help. |
RubiChess debug file for comparison. |
I discussed the game Viri vs. SF in Graham's chat and asked him for the logs of some Rubi games cause Rubi measures the lag between the engine and the GUI by comparing the move time from the engines pov (time difference t2-t1 from getting "go" at internal time t1 to sending "bestmove" at internal t2) and what the GUI thinks about the time of this move (t3 - t4 with "go wtime t3" for this move and "go wtime t4" for the next move). Main result is probably that you could blame the GUI: |
ugh.. 1.5s GUI overhead. Yeah, sure in that case one needs to set
it assumes the overhead is 10ms. |
I set the overhead in ChessGUI to 5000ms.
…On Fri, Jun 30, 2023 at 10:13 PM Joost VandeVondele < ***@***.***> wrote:
ugh.. 1.5s GUI overhead. Yeah, sure in that case one needs to set
Move Overhead type spin default 10 min 0 max 5000
Assume a time delay of x ms due to network and GUI overheads. This is useful to avoid losses on time in those cases.
it assumes the overhead is 10ms.
—
Reply to this email directly, view it on GitHub
<#4000 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AVOIVUQZHKERWWGQEVKUV7DXN2RFBANCNFSM5UYQI4RA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@GrahamCCRL: As I told you in chat: The engine doesn't know about the GUIs 5000ms grace overhead and will do depth 1 moves. SF (black) gets 123ms here:
And next move:
Engine gets negative time and needs to move immediately. |
The right thing here is to Receiving negative (even including zero) btime could lead to all kind of weird stuff. This is really a GUI bug. |
GUI overhead of 1.5 seconds is horrendous. Potentially other engines are having the same issues in that environment but go unnoticed. |
The binary for Berserk 11.1 given to Graham has a different default |
Why a special exe ? He can just change it. |
The UCI protocol does not indicate how much additional time will be given after the last move of a movestogo tc. Using this type of time control at all is probably not a good idea. |
as observed at CCRL and mentioned in discord, at a TC of N move in M seconds, without increment, the last move before the N moves are over can be played at small time, and particular very low depth (1). This leads to losses at this TC that are not necessary.
Some data:
https://discord.com/channels/435943710472011776/813919248455827515/969974503595712562
https://discord.com/channels/435943710472011776/724661489381670923/968608582960562288
The text was updated successfully, but these errors were encountered: