1st Mini Shogi Computer Association Championships 2017

[hgm]

I uploaded a new version of broadcast.exe to the same link. This one does deposit a game result as extra 'move' to the server. And it also sends the remaining clock time of the side that gets on move with the score/depth comment to each move. I also fixed a bug that would cause moves the deposition of which was delayed by connection lag to be deposited as the first moves of the next game.

I replaced the tbserver.cgi on the server by a version that recognizes the game-result codes, and marks the game as terminated in the game overview when it receives such a code.

I reformatted the viewer page, so that the important elements fit in a smaller window. It now also shows two clocks next to the board. The JavaScript used by the page does strip remaining time from the score/depth comments in the moves before displaying them, and uses the time to synchronize the clocks. The clock of the side to move will run if a game without result is loaded, and this will then also cause periodic polling to check if the game has grown.

[Ferdy]

I uploaded a new version of broadcast.exe to the same link. This one does deposit a game result as extra 'move' to the server. And it also sends the remaining clock time of the side that gets on move with the score/depth comment to each move. I also fixed a bug that would cause moves the deposition of which was delayed by connection lag to be deposited as the first moves of the next game.

I replaced the tbserver.cgi on the server by a version that recognizes the game-result codes, and marks the game as terminated in the game overview when it receives such a code.

I reformatted the viewer page, so that the important elements fit in a smaller window. It now also shows two clocks next to the board. The JavaScript used by the page does strip remaining time from the score/depth comments in the moves before displaying them, and uses the time to synchronize the clocks. The clock of the side to move will run if a game without result is loaded, and this will then also cause periodic polling to check if the game has grown.

Thanks I got the file testing now.

[Ferdy]

I replaced the tbserver.cgi on the server by a version that recognizes the game-result codes, and marks the game as terminated in the game overview when it receives such a code.

There are times when the result +/-/= were not appended even though the actual games were already finished.



The game record:

Code: Select all

[Event "Computer Chess Game"]
[Site "?"]
[Date "2017.01.25"]
[Round "3"]
[White "Sjaak II 1.4.1"]
[Black "TJshogi5x5 0.19"]
[Result "0-1"]
[TimeControl "180+2"]
[Variant "shogi"]
[FEN "rbsgk/4p/5/P4/KGSBR[-] w 0 1"]
[SetUp "1"]

{--------------
r b s g k
. . . . p
. . . . .
P . . . .
K G S B R
white to play
--------------}
1. Sd2 {-0.06/18} Sc4 {+0.00/14 4} 2. Gb2 {+0.60/17 9} Gd4 {-0.30/14 6} 3.
Bc2 {+0.45/17 7} Ba4 {-0.96/14 5} 4. Bxa4 {+0.45/16 5} Rxa4 {-0.80/14 8} 5.
B@c5 {+0.21/15 8} Gd5 {-1.00/13 8} 6. a3 {-0.03/14 4} Gxc5 {+1.40/14 12} 7.
axa4 {-0.21/14 6} B@d4 {+1.50/13 3} 8. R@c2 {-0.74/12 6} B@a3 {+3.70/12 3}
9. Rb1 {-3.52/13 4} Gb4 {+8.22/12 6} 10. Rxc4 {-10.87/13 5} Baxb2
{+14.20/12 5} 11. Rxb2 {-23.93/12 7} Bxb2 {+34.48/12 9} 12. Kxb2
{-159.80/12 21} G@b3 {+199.83/12 13} 13. Kc1 {-159.82/18 1.7} R@a1
{+199.85/12 5} 14. B@b1 {-159.84/8 0.1} Gxc4 {+199.87/12 11} 15. B@c2
{-159.86/7 0.1} Gxc2 {+199.89/9 2.7} 16. Kxc2 {-7.05/2 0.1} B@d3
{+199.91/9 0.1} 17. Sxd3 {-159.92/12 0.1} R@c3 {+199.93/7 0.1} 18. Kd1
{-159.94/2} Rxb1+ {+199.95/5 0.1} 19. S@c1 {-159.96/2 0.1} Rxc1+
{+199.97/3} 20. Ke2 {-159.96/2 0.1} +Re1# {+199.99/1 0.1}
{Xboard adjudication: Checkmate} 0-1

I reformatted the viewer page, so that the important elements fit in a smaller window. It now also shows two clocks next to the board.

I can't see the clocks on my page see image above. I am using google chrome browser on windows 7.



I encountered 2x already where winboard becomes unresponsive. I have not experienced this with the previous broadcaster. It seems like when I stop the tournament by stopping all games by pressing Mode->machine match, one of the board would get unresponsive.





I am using the *trn file in this test with concurrency of 2, stop the tournament then run again with 4 concurrency then stop again.

[Ferdy]

I uploaded a new version of broadcast.exe to the same link. This one does deposit a game result as extra 'move' to the server. And it also sends the remaining clock time of the side that gets on move with the score/depth comment to each move. I also fixed a bug that would cause moves the deposition of which was delayed by connection lag to be deposited as the first moves of the next game.

I replaced the tbserver.cgi on the server by a version that recognizes the game-result codes, and marks the game as terminated in the game overview when it receives such a code.

I reformatted the viewer page, so that the important elements fit in a smaller window. It now also shows two clocks next to the board. The JavaScript used by the page does strip remaining time from the score/depth comments in the moves before displaying them, and uses the time to synchronize the clocks. The clock of the side to move will run if a game without result is loaded, and this will then also cause periodic polling to check if the game has grown.

Another test using command line:

Code: Select all

-mg 16 -tc 5 -inc 3 -sgf mini_blitz_broadcast4.pgn -lgf minishogi-ch-8start.pgn -lgi -2 -debug -debugfile "///broadcast PASSWORD msca1"

In the 5th game I press Mode->machine match.

* Winboad is responsive and exit properly.
* In the first 4 games, the results (+/-/=) were prepended properly, see games 84 to 87.
* In the 5th game the (+) result was not there, see game 88. The result in the pgn output is 1-0.

[Ferdy]

See games 89 to 92.
game 89: result is prepended
game 90, 91 and 92: results were not prepended.

The fift game was between Sjaak and Lima, and winboard becomes unresponsive. I have not press the Mode->machine match in this case.

Restarted and the game continues at game 6, and can be found as game 93 in the game list.

Then unresponsive again between petit and crazywa.

[Ferdy]

Test 5, using trn file, with 1 concurrency, an RR tour.

1st game is game 96.
Winboard Crashed after the game.

Code: Select all

[Event "Computer Chess Game"]
[Site "?"]
[Date "2017.01.25"]
[Round "1"]
[White "CrazyWa 1.0.2"]
[Black "NebiyuAlien 1.46"]
[Result "0-1"]
[TimeControl "180+2"]
[Variant "shogi"]
[FEN "rbsgk/4p/5/P4/KGSBR[-] w 0 1"]
[SetUp "1"]

{--------------
r b s g k
. . . . p
. . . . .
P . . . .
K G S B R
white to play
--------------}
1. Bc2 {+0.26/14} Bc4 {+0.06/21 6} 2. Gb2 {+0.22/14 5} Sb4 {+0.12/22 6} 3.
Sd2 {+0.15/14 7} Gd4 {+0.22/21 7} 4. Rd1 {-0.06/12 3} Rc5 {+0.04/21 8} 5.
Rc1 {+0.08/13 5} Ra5 {+0.00/20 7} 6. Re1 {-0.03/13 4} Kd5 {+0.06/20 6} 7.
Rd1 {-0.07/13 6} Ke5 {+0.16/20 6} 8. Kb1 {-0.15/12 2.8} Rb5 {+0.98/20 1:13}
9. Ba4 {-0.33/13 3} Ra5 {+0.94/20 4} 10. a3 {-0.39/13 4} Rxa4 {+2.36/20 3}
11. axa4 {-0.75/13 4} B@b3 {+2.02/19 4} 12. Rc1 {-0.57/12 4} Bxa4
{+2.26/19 3} 13. Ka1 {-1.62/12 7} P@d3 {+3.44/19 4} 14. Se1 {-1.65/13 7}
Kd5 {+3.28/20 6} 15. Kb1 {-0.83/13 3} e3 {+3.56/19 3} 16. Ka1 {-1.64/14 6}
Bcb3 {+5.06/21 22} 17. R@b1 {-2.85/13 4} Ke4 {+4.38/18 2.6} 18. Ga2
{-4.35/14 5} Kd5 {+6.54/19 2.5} 19. Rb2 {-4.59/13 4} Gc4 {+8.94/18 2.9} 20.
Sd2 {-6.09/12 5} dxd2 {+13.22/17 2.9} 21. Rxd2 {-8.73/12 6} S@d3
{+13.88/18 2.8} 22. Rb2 {-8.87/11 4} Sc3 {+15.10/17 2.9} 23. P@b1
{-10.25/12 7} Sxb2 {+23.10/18 2.3} 24. Gxb2 {-1000.09/13 4} R@e2
{+27.02/17 2.3} 25. Rxc4 {-1000.07/13 4} Sxc4 {+29.92/17 2.5} 26. G@c2
{-1000.06/16 4} Rxc2 {+299.84/19 2.8} 27. S@a2 {-1000.06/15 6} G@a3
{+299.86/19 3} 28. Gxa3 {-1000.05/68 4} Bxa2 {+299.88/21 3} 29. G@c1
{-1000.04/98 1.0} Rxc1+ {+299.90/22 3} 30. Gxa2 {-1000.03/98 0.1} +Rxb1
{+299.92/19 2.7} 31. Kxb1 {-1000.02/8 0.1} G@c2 {+299.94/27 2.6} 32. Ka1
{-1000.01/2} R@b1# {+299.96/29 3}
{Xboard adjudication: Checkmate} 0-1

[hgm]

OK, there seem to be several problems. The most mysterious is that you don't see the clocks. I see them both with Chrome and FireFox. It could be a caching problem, however. The clocks are part of the board, which is a HTML table that is generated after the page loaded by the JavaScript the page links to. It could be that the old version of this JavaScript file is still cached in your browser. In FireFox, when I reload a page, it does not automatically reload everything the page refers to (like images and scripts); I have to do press Shift during reload for that. The implementation of the clocks is a bit fishy, because the first and the last rank of the board table have once cell more than the other ranks, but I don't think this is forbidden in HTML.

The other problems all seem to be due to slow or unreliable connections. For every move of a broadcasted game, the broadcaster fetches a page

hgm.nubati.net/cgi-bin/tbserver.cgi?game=msca1&cmd=<MOVE>&user=<FIRSTENGINE>&pw=<PASSWORD>&nr=<GAMENR>

which will be a plain-text page with the single line "Move accepted" on it if depositing the move succeeded (i.e. the connection to the server could be made, the password and game number were valid, etc.).

Because it is pointless to continue broadcasting if a move is missing, failure to get the 'Move accepted' response just leads to indefinite retrying. There is no retrying yet for the server accesses that create a game, or deposit the game result. If creation of a game does not get the reply "Added game: NR", the broadcaster will not have a valid game number to use for depositing moves, and will refrain from attempting the latter for the remainder of the game. If depositing a result code fails, the game will be never marked as completed on the server, as the broadcaster simply goes on with the next game.

Since I believe the broadcaster logic to be correct, (i.e. it would not use invalid game numbers, engine names or passwords) the only cause for not getting the "Move accepted" response should be network failure (the request timing out). If that keeps happening for a long period, the broadcaster thread will get stuck at that move, and don't read moves from the internal pipe. This pipe will then eventually fill up with data (I think by default pipes can buffer 64KB on Windows). The GUI thread will then block when it tries to write the next move received from the GUI into the pipe, and will stop reading from the GUI. This means the GUI->broadcaster pipe will fill up too. (And very quickly, because this is unfiltered debug output which also includes all thinking output.) After that WinBoard will block while writing debug information, making it unresponsive.

I had hoped that the pipe buffer between the thread that reads from the GUI and the thread that access the network would be enough to prevent this scenario. But apparently it isn't. I guess I could increase the capacity of the buffer pipe, but if the server really becomes inaccessible, the pipe will always fill up eventually.

Other solutions could be to only do a limited number of retries on move deposition, and if these all fail, abort broadcasting of that game. (So that the network thread would just read and discard all remaining moves from that game from the buffer pipe.) I don't know if there could be indefinite waits on a single network request; these would still be able to wreck such a scheme. I could have the GUI thread count the number of lines it writes into the pipe, and the network thread count the lines it reads, so that the GUI thread can see how many lines are buffered, and refrain from writing for the remainderof a game if this number gets too high.

[Ferdy]

OK, there seem to be several problems. The most mysterious is that you don't see the clocks. I see them both with Chrome and FireFox. It could be a caching problem, however.

That was the problem indeed, after clearing my browsing data, I can see the clock now and the moves are now updated in the viewer.

[Ferdy]

One more observation, the clock of one player is not right because the viewer updates the board after 2 moves are received.
It would appear that it is always black to play, once black played the move, the viewer is not updated, but once white played the move, the viewer will update immediately moving the black move and the white move and it is black to move again.

[hgm]

Ughh. The problem is that the moves are accompanied by the time on the clock that they set running. So I cannot use the time sent with the forelast move for the other clock, because the time used for the last move would still have to be subtracted from that.

I used this method because the broadcaster takes the times from the time and otim command to the first engine, just as it takes the moves from the move and usermove commands from/to the first engine. This because in operator-mediated tournaments like the UEC Cup there is no second engine. But only the usermove command will be accompanied by time/otim. When the first engine does produce its move, WinBoard would only divulge its clocks when it sends it to the second engine (if it does that at all). So the latest time/otim you have is from before the first engine started thinking about that move. 'otim' will still be valid, because the opponent clock was not running, but 'time' should have decreased.

I guess it would be better to send the time left of the side that provided the move; then every received move of a game can be used to sync the clock of the player making it. The broadcaster would then have to derive that for the first engine from the time command before the move, and use the msec time stamps in the debug file for that time command and the engine's move command to calculate the remaining clock time. (This would miss any increments, however.) The second engine's time is no problem; it is sent as 'otim' to the first engine before the second engine's move is obtained from the 'usermove' to the first.

Note that the displayed clocks will always be imprecise, because they can only be set running when a game that was fetched during polling contains new moves, and the viewer has no idea of how much time elapsed between the deposition of that move and the fetching.