Winboard Forum

I have a very nasty problem with Winboard under Windows XP, SP2:

Once every 5 games or so, Winboard cannot hear one of the engines. As a consequence it starts just counting down the clock with zero or one moves played on the display (depending if this engine has white or black).

This totally wrecks my ability to test my engine: if I set up a match of 50 or 100 games to run overnight, the next morning only 3 games have been played, and in the 4th one side is at -7:30:00 and counting.

This failure to set up communication happens also frequently when I start Winboard by hand. From the task manager I can then see that the engine(s) do start up, use CPU heavily as the think up a move, and then become idle as they have send their move to Winboard. Winboard, however, just counts them down forever.

This is not a problem of my own engine; it also happens when I play, say, GNUChess against TSCP.

Have any of you seen similar behavior, and what could be done against it? It would already be a big nuisance if 20% of the games are randomly awarded to one of the opponents without play, after waiting out the flag, but I could correct that from the PGN fil, I suppose. But now 95% of the games is not played, as Winboard just waits forever...

Hi !

Can you send me a winboard.debug file for an example ?
I'll take a look on it

Best,
Daniel

Hi HG

Which version of Winboard are you using ? I guess this communication problem has been fixed in the last winboard_x. At least it does not happen here, as you can see by the broadcasts

I had this issue with... Arena 1.1 (around 1 game out of 20).

Olivier

OK, I am using the version from Tim Mann's site. So perhaps I should try the winboard_x instead, see if that solves it. (The download of that seemed to be in a format that my unzipper cannot handle, though...)

I will also try to save a debug when it happens again. I think I did look in the debug once, and IIRC there was nothing to see. Just no input from one of the engines at all. Winboard just sends it commands, and then starts waiting for a while, to see if the engine complains about them. (I can see that the message "starting first/second engine" is displayed for an unusually long time in such cases.) Apparently it times out while waiting, and then assumes that this must mean the engine has understood all the commands. It then sends it a go and sets the clock running. But if the pipe from that engine to Winboard is somehow broken or clogged, you would not notice it through that protocol.

Hello HG,

Forcing the engines to kill their process and restart after every game may help.

This is taken from the winboard protocol info >

xboard normally reuses the same chess engine process for multiple games. At the end of a game, xboard will send the "force" command (see below) to make sure your engine stops thinking about the current position. It will later send the initString again to start a new game. If your engine can't play multiple games, you can disable reuse either with the "feature" command (beginning in protocol version 2; see below) or with xboard's -xreuse (or -xreuse2) command line option. xboard will then ask the process to quit after each game and start a new process for the next game.

Jim.

Well, under PSWTM each engine process plays only a single game, and after that game is finished, even the Winboard process is killed. So everything starts from scratch (or rather, it should) every game, even if the same two engins ply again.

But (so far) winboard_x seems to solve it. Last night I played 100 2-min games, and they all finished!

Some engines behave strangely under such short time control: sometimes, s soon as the get out of book nd strt to use their hash table, they are basically out of business for about one minute while their clock is running, and Windows is expanding their memory footprint to the requested size. That way they lose half their thinking time. This in particular occurs the first game every engine plays; after that apparently Windows can allocate it the chunk of memory that they occupied before and left empty while the quitted. If, in the mean time, I do other things on that computer, it might occur again.

In Joker I access the complete hash table to make sure Joker is all loaded before announcing itself to the GUI, to prevent the GUI setting Joker's clock running while it is not yet ready to play.