Beating Stockfish 14 on time

[Henk]

Skipper had not won from stockfish 14 before. Only from stockfish 13.

Elo difference say 1400-1500
[pgn]
[Event "Computer Chess Game"]
[Site "LAPTOP-1FK7MTIP"]
[Date "2021.11.28"]
[Round "-"]
[White "Skipper_8_19_2_3"]
[Black "Stockfish 14"]
[Result "1-0"]
[TimeControl "60"]
[Annotator "1. +0.39 1... -0.47"]

1. Nf3 {+0.39/7} d5 {-0.47/22 4} 2. d4 {-0.01/6 1.0} e6 {-0.19/20 0.1} 3.
c4 {+0.02/6 1.0} Nf6 {-0.24/19 0.1} 4. cxd5 {+0.01/6 1.0} exd5
{-0.29/19 1.0} 5. Nc3 {-0.25/6 0.9} c6 {-0.17/19 0.7} 6. Bf4 {+0.14/5 0.9}
Bf5 {-0.25/19 1.2} 7. Qb3 {+0.16/5 0.9} Qb6 {+0.24/16 0.6} 8. Qxb6
{-0.03/7 0.9} axb6 {+0.68/18 0.6} 9. Nh4 {-0.32/5 0.9} Be6 {+1.03/19 1.1}
10. e3 {-0.38/5 0.9} Ne4 {+1.38/18 0.7} 11. Bd3 {+0.01/6 0.9} Bb4
{+1.24/20 0.2} 12. O-O {+0.06/6 0.8} Bxc3 {+1.63/20 1.4} 13. bxc3
{+0.14/7 0.8} Nxc3 {+1.72/19 0.3} 14. Rfc1 {+0.65/6 0.8} Na4 {+1.65/21 0.5}
15. Nf5 {+0.96/7 0.8} Bxf5 {+1.74/19 0.2} 16. Bxf5 {+0.97/7 0.8} O-O
{+1.63/23 4} 17. Rab1 {+1.82/5 0.8} g6 {+1.87/24 5} 18. Bh3 {+1.42/7 0.8}
b5 {+1.68/22 1.0} 19. g4 {+1.06/5 0.8} Nb6 {+3.41/16 0.6} 20. Bg2
{+0.78/5 0.7} Rxa2 {+4.15/17 0.6} 21. e4 {-0.60/6 0.7} dxe4 {+3.13/21 2.2}
22. Bxe4 {-0.89/6 0.7} Ra4 {+3.10/20 0.7} 23. Rd1 {-0.67/5 0.7} Na6
{+3.93/17 0.5} 24. h4 {-0.80/5 0.7} Rd8 {+4.34/16 0.1} 25. Be3
{-0.96/5 0.7} Nc7 {+5.24/17 0.6} 26. Bc2 {-1.15/5 0.7} Raa8 {+5.14/20 2.0}
27. Bg5 {-1.71/5 0.7} Re8 {+5.06/21 2.8} 28. Re1 {-1.60/5 0.7} Nbd5
{+5.46/18 1.1} 29. Rxe8+ {-1.95/7 0.6} Rxe8 {+5.46/19 0.7} 30. h5
{-2.32/6 0.7} Ne6 {+5.30/22 4} 31. Be3 {-2.35/6 0.6} Nc3 {+5.76/19 1.9} 32.
Rb4 {-2.37/6 0.6} Nc7 {+5.69/21 1.7} 33. h6 {-1.83/6 0.6} N7d5
{+6.15/19 0.5} 34. Rb2 {-2.65/8 0.6} Nxe3 {+7.76/17 0.4} 35. fxe3
{-2.70/8 0.6} Rxe3 {+7.74/19 0.2} 36. Kf1 {-2.88/6 0.6} Kf8 {+7.95/17 0.5}
37. Rb3 {-2.88/7 0.6} Ke7 {+7.79/19 0.1} 38. Ra3 {-3.03/6 0.6} Kf6
{+7.75/19 0.9} 39. Ra7 {-2.95/7 0.6} Re7 {+7.87/18 0.5} 40. Ra3
{-4.01/7 0.6} Nd5 {+8.23/21 1.3} 41. Kf2 {-4.05/7 0.6} Kg5 {+8.45/16 0.4}
42. Rh3 {-4.99/7 0.5} Nf6 {+8.44/21 2.1} 43. Bd1 {-4.19/6 0.5} Ne4+
{+8.51/16 0.2} 44. Ke3 {-4.66/7 0.5} Nf6+ {+8.23/20 3} 45. Kf2
{-5.29/7 0.5} Ne4+ {+8.56/16 0.6} 46. Ke3 {-4.86/7 0.5} b4 {+8.53/17 0.2}
47. Bf3 {-4.67/8 0.5} Nc5+ {+9.15/18 0.5} 48. Kd2 {-5.35/8 0.5} Rd7
{+8.74/18 0.2} 49. Kc2 {-5.81/7 0.5} Rxd4 {+10.32/14 0.2} 50. Be2
{-7.04/7 0.5} Re4 {+9.76/18 1.1} 51. Bd1 {-6.19/7 0.5} f6 {+8.99/19 1.7}
52. Kc1 {-5.66/6 0.5} Re5 {+9.15/18 0.1} 53. Bf3 {-6.26/7 0.4} Re3
{+10.30/14 0.2} 54. Kd2 {-7.04/8 0.4} Rd3+ {+10.69/14 0.3} 55. Kc2
{-7.17/8 0.4} Rc3+ {+11.34/15 0.2} 56. Kd1 {-7.69/8 0.4} Ne4
{+12.23/14 0.2} 57. Bxe4 {-9.68/8 0.4} Rxh3 {+12.92/14 0.2} 58. Bg2
{-10.28/6 0.4} Rh2 {+14.77/20 0.2} 59. Bf3 {-11.31/7 0.4} Kf4
{+17.81/18 0.2} 60. Be2 {-11.30/7 0.4} b3 {+68.08/29 0.1} 61. Bc4
{-12.44/6 0.4} b2 {+68.18/28 0.3} 62. Ba2 {-12.72/7 0.4} Kxg4
{+70.92/27 0.3} 63. Be6+ {-14.53/7 0.4} Kf4 {+99.83/27 0.3} 64. Ba2
{-14.36/6 0.4} Ke3 {+99.89/48 0.2} 65. Bb1 {-15.16/7 0.4} b5
{+99.91/79 0.2} 66. Ba2 {-327.58/7 0.4} b4 {+99.93/209 0.4} 67. Bb1
{-327.60/9 0.4}
{White wins on time} 1-0
[/pgn]

[dangi12012]

What gui did you use? Setting btime and wtime is the responsibility of the uci commanding program.

[Henk]

What gui did you use? Setting btime and wtime is the responsibility of the uci commanding program.

I used Winboard. What is btime, wtime? Never heard of. Skipper does not use uci.

[R. Tomasi]

What gui did you use? Setting btime and wtime is the responsibility of the uci commanding program.

I used Winboard. What is btime, wtime? Never heard of. Skipper does not use uci.

BTIME and WTIME are Winboard commands, not UCI.

[hgm]

No, btime and wtime are parameters to the UCI go command. The CECP commands are time and otim.

[R. Tomasi]

No, btime and wtime are parameters to the UCI go command. The CECP commands are time and otim.

I stand corrected. Thanks for pointing that out!

[dangi12012]

My point is that if your GUI does not do time management correctly the best engine timing heuristic is useless.

[hgm]

True. But to know whether the engine or the GUI is at fault you would have to see the log. And even then it can still be the OS its fault, by denying the engine CPU at a critical moment.

[mar]

SF was clearly mating, looks like maybe the communication was flooded with engine output?
however what I (and practically everyone else) do is to delay the initial engine output from search when actually playing a game for say 200msec or so - and even if the move takes less to complete, only the final PV and move is output at the end of the search
pretty sure SF does something very similar to this

looking at UCI2WB (assuming SF was playing via a wrapper) - I have to say that using GetTickCount()
to measure elapsed time is not the best way, I still get ~16msec granularity on my Win10 machine today
also: UCI supports 1ms resolution while CECP's resolution is only 10msec

ideally one wants sub-msec timers for either protocol (like QueryPerformanceCounter). because imagine you call GetTickCount(), get some value and a couple of microseconds later you suddenly jump forward 16msec - and that's really a lot

to be fair - it's possible that UCI2WB already sends somewhat underestimated remaining time to the engines to compensate for this

it's hard to say for sure without a log and what TC was used etc

[hgm]

All my engines use GetTickCount too, so sending time in msec wouldn't help them much. WinBoard also uses the system clock that ticks every 16msec, as will be obvious from the time stamps in the debug file. I once tried to let WinBoard use a more accurate timer, but the recommended Windows API calls did not seem to be available on my system.

Engines should be aware that there can be communication delays, so that they cannot use the full time the GUI says they have available. I thought that Stockfish had an option to set this. Of course Henk doesn't want to use that option.

Because of unpredictable communication delays, it is not advisable to rely on millisecond timing. For all you know the OS might still use the 60Hz clock for task scheduling. For ultra-fast games it would be better to take timing decisions by node count.