ChessGUI Timer Problem

[Modern Times]

There may be still other timer problems such as ChessGUI’s questionable use of a timeout fudge number to prevent forfeits.

You can be sure that some other GUIs do the same thing behind the scenes, a built-in tolerance, they just don't declare it.

[D Sceviour]

You can be sure that some other GUIs do the same thing behind the scenes, a built-in tolerance, they just don't declare it.

Does Winboard use a timeout fudge number to prevent forfeits?[/quote]

[abulmo]

Here is a game between a development version of my program and Crafty 22.10, where Crafty exhibits the problem described with ChessGUI & Schooner

[White "Amoeba 134"]
[Black "Crafty-22.10"]
[Result "1-0"]
[TimeControl "40/60"]

1. d4 Nf6 2. c4 c5 3. d5 e6 4. Nc3 exd5 5. cxd5 d6 6. e4 g6 7. Nf3 Bg7 8.
Bd3 {+1.25/15 2.6} O-O {+0.80/13 1.6} 9. O-O {+1.13/16 1.4} Re8
{+0.72/13 2.3} 10. Bf4 {+1.29/13 1.4} c4 {+0.68/13 1.7} 11. Bc2
{+1.11/17 2.8} Qb6 12. Rb1 {+1.10/18 3} Qa6 13. Nd4 {+1.62/17 2.6} Bd7
{+0.94/12 3} 14. a4 {+1.55/18 1.6} Nh5 {+1.13/13 3} 15. Be3 {+1.90/18 2.6}
Qa5 {+1.25/14 1.7} 16. Ncb5 {+2.00/20 3} Be5 {+0.88/12 1.6} 17. b4
{+2.22/19 2.0} cxb3 {+0.87/13 1.7} 18. Nxb3 {+2.00/17 1.2} Qd8 19. f4
{+2.00/18 1.5} Bxb5 {+0.71/13 1.7} 20. axb5 {+2.04/17 0.8} Bh8
{+0.84/13 1.1} 21. Qf3 {+1.87/15 3} Qe7 22. Rfe1 {+1.99/14 1.0} a5
{+0.84/11 2.5} 23. g4 {+1.85/15 1.8} Nf6 24. g5 {+1.54/14 1.0} Nfd7
{+0.59/11 1.6} 25. f5 {+1.26/16 1.4} Ne5 26. Qg2 {+1.45/16 1.0} f6
{+0.51/13 0.7} 27. Nd4 {+2.56/15 1.0} a4 {+0.53/13 2.2} 28. fxg6
{+2.26/16 2.2} hxg6 {+0.70/13 2.2} 29. gxf6 {+2.30/17 0.7} Bxf6 30. Rf1
{+2.18/16 1.7} Rc8 {+0.78/11 2.4} 31. b6 {+2.00/15 0.7} a3 {+0.52/12 1.5}
32. Bb3 {+1.73/16 0.6} Nbd7 {+0.62/12 2.3} 33. Nb5 {+1.83/16 0.7} Rf8
{+0.64/12 4} 34. Nc7 {+1.92/16 1.7} Rab8 35. Ne6 {+2.62/16 1.4} Rf7
{+0.98/13 2.5} 36. Rbc1 {+2.66/15 2.1} Bh4 {+1.05/13 2.6} 37. Bf4
{+3.29/18 2.5} g5 {+1.50/12 1.7} 38. Bxe5 {+3.16/20 2.1} Nxe5
{+3.16/14 1.3} 39. Rc7 {+3.98/19 2.8} Rxf1+ 40. Qxf1 {+3.67/21 3} Nd7 41.
Qf5 {+3.10/20 1.5} Ra8 {+4.06/14 10} 42. Ba2 {+5.44/17 1.5} Kh8
{+6.47/16 25} 43. Rxb7 {+5.64/20 1.5} Rc8 {+5.07/15 14} 44. Rc7
{+8.44/18 1.5} Rg8 {+9.73/15 8} 45. b7 {+10.19/17 1.0} Qf6 {+10.58/15 5}
46. Qxf6+ {+12.38/22 1.5} Nxf6 {+12.19/17 1.8} 47. Rc8 {+13.52/25 1.0} Nd7
48. Nf8 {+14.22/24 1.5}
{White wins on time} 1-0

Similar behaviour with a notable exception: the GUI used is xboard 4.9.1 and the setboard command is not used here, but each move is sent to crafty. It looks like (I have not checked the code) that this version* of Crafty only increments the ply counter when it actually plays the move, not when it receives a move from the GUI.

So, examining the games already played on CCRL will not necessarily indicate a "buggy" ChessGUI, the chess engine may be at fault, not only by partially interpreting the setboard FEN string, but also by only counting its own plies.

* Other Crafty versions I have does not show this bug.

[hgm]

Does Winboard use a timeout fudge number to prevent forfeits?

No, it strictly enforces the time limits. It would not make sense to do otherwise, as often the time limits are imposed by an ICS for which WinBoard is just the client, and the ICS would not respect any fudge factor WinBoard would apply.

So, examining the games already played on CCRL will not necessarily indicate a "buggy" ChessGUI, the chess engine may be at fault, not only by partially interpreting the setboard FEN string, but also by only counting its own plies.

Indeed, this is a well-known problem that many WB engines suffer from. I am shocked to learn this also holds for Crafty, though.

But I think CCRL is well aware of this. In any case, such engines would make the same mistake on all GUIs they are tested on. So it would just count as a bug that lowers their rating in classical TC games with external book compared to games without book or at incremental TC. So it is just an engine problem.

If engines systematically are weakened on one GUI, and not on another, it would corrupt the entire list when they would be treated as having the same rating, though. There would effectively be a Crafty-ChessGUI and a Crafty-anythingElse with very different ratings, but they would unjustly get assigned some average rating. This would then hurt the rating of opponents that play against it, which would be overly awarded for their performance on ChessGUI, where Crafty is weak, and dealt short on other GUIs, where Crafty is strong.

[jdart]

IMHO, it violates the rules of chess because the 3-fold repetition and 50-move rule are not available.

Yes, because of these issues the GUI using setboard in this case is just broken IMO. This is why uci sends the whole move list.

--Jon

[hgm]

This is why uci sends the whole move list.

That doesn't have anything to do with UCI. In UCI you can also send "position fen" and omit all preceding moves. It is broken, like you say, but just a flaw in the GUI design that is independent from the protocol.

[Werner Taelemans]

by intuition (but in line with the spec, in my view) I'd say that I get a certain amount of time for 40 moves (for example), so I can use it to think about 40 moves, not about (41 - full move number). A chess game that starts with a position different from the standard opening position is still a chess game where, with conventional time control, MPS moves shall be made within a given time.

I agree. Here's a quote from an older spec:

The number of moves given in the level command (when non-zero) should be taken as the number of moves still to do
before the specified time will be added to the clock, if the "level" command is received after some moves have already
been played. The time given should be interpreted as the time left on its clock (including any time left over from the
previous sessions), and not necessarily the time that will be added to the clock after the specified number of moves has been played.

Changing the level relative to the board position or changing the board position relative to the level, what's the difference? It's a different POV of the same situation. This shouldn't change the meaning of the number of moves in the level command.

[hgm]

This quoted spec deals with the situation where a level command would be received during a game in progress. Currently the possibility to do so is not even implemented in WinBoard; an attempt to change the TC during a game will be met with a popup "changing TC during a game is not implemented". I added this spec as a step towards implementing multi-session TC, like 1 hour for the first 40 moves, then 15 min for the next 20 moves, and then 5 min for the rest of the game. WB protocol does not allow that to be told to the engine at once, so you would send 'level 40 60 0' to set the engine for the first session. But then it would expect to get another hour, to use for the next 40 moves.

So to prevent it would forfeit, a GUI could send 'level 60 18 0' after the engine made its 40th move (supposing that 3 min was left). With the most-likely implementation of the level command in existing engines this would make the engine think it would get new time at move 60, which is exactly what will happen.

None of this is supposed to have any effect on a level command sent at the start of a game.