Beating Stockfish 14 on time

[dangi12012]

IMO its GUI delay in parsing output and resending the "go" command.
SF can be very agressive in "bestmove" output. And keep in mind that even when you give it literally ZERO nodes there can still be a bestmove from the PV stored earlier.

[Henk]

It's already a record that game lasted more than 65 moves.

[hgm]

IMO its GUI delay in parsing output and resending the "go" command.
SF can be very agressive in "bestmove" output. And keep in mind that even when you give it literally ZERO nodes there can still be a bestmove from the PV stored earlier.

In the absence of any data that is pure speculation. You might as well think that it is the engine polling the clock too infrequently.

[JohnWoe]

If Stockfish never loses on time on Cutechess but on GUI X. Then the GUI X is in blame?
Tho SF has only 10ms MoveOverhead. Which is crazy.
In Mayhem I have 100ms. But still I see time losses on XBoard.

In XBoard/Winboard the clock works weird. It probably calculates time for graphical movements too?

[dangi12012]

If Stockfish never loses on time on Cutechess but on GUI X. Then the GUI X is in blame?
Tho SF has only 10ms MoveOverhead. Which is crazy.
In Mayhem I have 100ms. But still I see time losses on XBoard.

In XBoard/Winboard the clock works weird. It probably calculates time for graphical movements too?

You can measure overhead with "go" and "stop" sent instantly and measuring when SF reports a "bestmove". I guess its less than 1ms - but its just a guess.

If the gui does move pieces synchronously and that takes 20ms and it subtracts that from SFs time then yes it should have sent wtime-20 to begin with.

[JohnWoe]

If Stockfish never loses on time on Cutechess but on GUI X. Then the GUI X is in blame?
Tho SF has only 10ms MoveOverhead. Which is crazy.
In Mayhem I have 100ms. But still I see time losses on XBoard.

In XBoard/Winboard the clock works weird. It probably calculates time for graphical movements too?

You can measure overhead with "go" and "stop" sent instantly and measuring when SF reports a "bestmove". I guess its less than 1ms - but its just a guess.

If the gui does move pieces synchronously and that takes 20ms and it subtracts that from SFs time then yes it should have sent wtime-20 to begin with.

Yes.
If only you could set 1 second on XBoard/WinBoard you could easily see this bug??? No such luxury.

I could measure it in my engine(I know it better than SF) in go -> bestmove and compare it to next time left XBoard sends. Hoping for someone else to do it

However I moved my clock higher in go command just in case...

[Mergi]

Interesting, I had some similar problems with SF's time management as well. When i was running a few testing games against it, i remember once seeing that it blew all it's remaining time during the middle game and then towards the end it was sending best move immediately with search depth of 0, as it didn't have almost any time left. Can't remember exactly what the time control was ... probably something around 10s with no increments.

[Guenther]

If Stockfish never loses on time on Cutechess but on GUI X. Then the GUI X is in blame?
Tho SF has only 10ms MoveOverhead. Which is crazy.
In Mayhem I have 100ms. But still I see time losses on XBoard.

In XBoard/Winboard the clock works weird. It probably calculates time for graphical movements too?

You can measure overhead with "go" and "stop" sent instantly and measuring when SF reports a "bestmove". I guess its less than 1ms - but its just a guess.

If the gui does move pieces synchronously and that takes 20ms and it subtracts that from SFs time then yes it should have sent wtime-20 to begin with.

Yes.
If only you could set 1 second on XBoard/WinBoard you could easily see this bug??? No such luxury.

I could measure it in my engine(I know it better than SF) in go -> bestmove and compare it to next time left XBoard sends. Hoping for someone else to do it :lol:

However I moved my clock higher in go command just in case...

Wrong several times...

1. Ofc you can set seconds (base and even ms inc) '0:01' == base 1s
2. Comparisons were done alreday often in the past and xboard/winboard had always less overhead than any other GUIs (before CuteChessGui)
3. Ofc even a slightly knowledgeable user knows that he has to set move animation to false for fast tcs

Point 3 surely completely escaped henk, who is often doing things the wrong way (the game was sudden death tc BTW)
Also SF has suboptimal time management for tcs besides inc tcs.
OTH I am 99% sure (knowing henk) it was a user error with a quirky setup because I doubt SF will spend 0.4 sec for the moves in the end in SD tc.
IMO the whole thread is just hot air.

[dangi12012]

If Stockfish never loses on time on Cutechess but on GUI X. Then the GUI X is in blame?
Tho SF has only 10ms MoveOverhead. Which is crazy.
In Mayhem I have 100ms. But still I see time losses on XBoard.

In XBoard/Winboard the clock works weird. It probably calculates time for graphical movements too?

You can measure overhead with "go" and "stop" sent instantly and measuring when SF reports a "bestmove". I guess its less than 1ms - but its just a guess.

If the gui does move pieces synchronously and that takes 20ms and it subtracts that from SFs time then yes it should have sent wtime-20 to begin with.

Yes.
If only you could set 1 second on XBoard/WinBoard you could easily see this bug??? No such luxury.

I could measure it in my engine(I know it better than SF) in go -> bestmove and compare it to next time left XBoard sends. Hoping for someone else to do it

However I moved my clock higher in go command just in case...

Wrong several times...

1. Ofc you can set seconds (base and even ms inc) '0:01' == base 1s
2. Comparisons were done alreday often in the past and xboard/winboard had always less overhead than any other GUIs (before CuteChessGui)
3. Ofc even a slightly knowledgeable user knows that he has to set move animation to false for fast tcs

Point 3 surely completely escaped henk, who is often doing things the wrong way (the game was sudden death tc BTW)
Also SF has suboptimal time management for tcs besides inc tcs.
OTH I am 99% sure (knowing henk) it was a user error with a quirky setup because I doubt SF will spend 0.4 sec for the moves in the end in SD tc.
IMO the whole thread is just hot air.

Why would the gui overhead even go against engine times? I think the gui shouldnt use the engines time to do anything at all. If gui says to engine you have 5ms time - the engine should be able to take 4ms and expect the next move to be 1ms.
Everthing else is a programming error of the gui!

[JohnWoe]

If Stockfish never loses on time on Cutechess but on GUI X. Then the GUI X is in blame?
Tho SF has only 10ms MoveOverhead. Which is crazy.
In Mayhem I have 100ms. But still I see time losses on XBoard.

In XBoard/Winboard the clock works weird. It probably calculates time for graphical movements too?

You can measure overhead with "go" and "stop" sent instantly and measuring when SF reports a "bestmove". I guess its less than 1ms - but its just a guess.

If the gui does move pieces synchronously and that takes 20ms and it subtracts that from SFs time then yes it should have sent wtime-20 to begin with.

Yes.
If only you could set 1 second on XBoard/WinBoard you could easily see this bug??? No such luxury.

I could measure it in my engine(I know it better than SF) in go -> bestmove and compare it to next time left XBoard sends. Hoping for someone else to do it

However I moved my clock higher in go command just in case...

Wrong several times...

1. Ofc you can set seconds (base and even ms inc) '0:01' == base 1s
2. Comparisons were done alreday often in the past and xboard/winboard had always less overhead than any other GUIs (before CuteChessGui)
3. Ofc even a slightly knowledgeable user knows that he has to set move animation to false for fast tcs

Point 3 surely completely escaped henk, who is often doing things the wrong way (the game was sudden death tc BTW)
Also SF has suboptimal time management for tcs besides inc tcs.
OTH I am 99% sure (knowing henk) it was a user error with a quirky setup because I doubt SF will spend 0.4 sec for the moves in the end in SD tc.
IMO the whole thread is just hot air.

Why would the gui overhead even go against engine times? I think the gui shouldnt use the engines time to do anything at all. If gui says to engine you have 5ms time - the engine should be able to take 4ms and expect the next move to be 1ms.
Everthing else is a programming error of the gui!

This.
Whatever happens in the GUI shouldn't have any effect thinking time for the engine. If properly implemented.
Mayhem for example has 100ms MoveOverhead. So Mayhem never uses more than "time available" - 100ms.
Time losses are only possible on very weak HW.

More XBoard bugs. How is f5g6 illegal move? Look at this game:
[pgn][Event "Computer Chess Game"]
[Site "pc"]
[Date "2021.12.04"]
[Round "-"]
[White "Mayhem 6.4"]
[Black "Mayhem 6.4"]
[Result "0-1"]
[TimeControl "60+1"]
[FEN "rnbqkbnr/pppppppp/8/PPPPPPPP/PPPPPPPP/PPPPPPPP/PPPPPPPP/PPPPKPPP w kq - 0 1"]
[SetUp "1"]

{--------------
r n b q k b n r
p p p p p p p p
. . . . . . . .
P P P P P P P P
P P P P P P P P
P P P P P P P P
P P P P P P P P
P P P P K P P P
white to play
--------------}
1. h6 {-13,20/18} g6 {+13,06/17 3}
{polyglot: resign (illegal engine move by white: f5g6)} 0-1

[/pgn]