Problem with pipes

[Edmund]

For the Engine <> GUI communication I am calling PeekNamedPipe every couple thousand of nodes + everytime before a PV is sent. If it receives the "Stop" command it sets an abort flag and the searchtree unwinds.

Usually this system seems to work, but recently I found out that there are problems with positions where the Engine is sending lots of lines to the GUI. (eg in Positions with forced wins or draws) There it takes the Engine way too long to recognize the Stop command.

Eg. A mate in 1 Position (current implementation is that the engine doesn't stop the search if no better mate is possible - but searches till the maximum depth of 100)

Code: Select all

472.189-->1:position fen 8/8/8/8/8/7K/R7/7k w - - 0 1
472.189-->1:go infinite
472.189<--1:info depth 1 score cp 1045 time 0 nodes 2 nps 0 pv a2a7
472.189<--1:info depth 1 score cp 1051 time 0 nodes 3 nps 0 pv h3g4
472.204<--1:info depth 2 score cp 1051 time 0 nodes 21 nps 0 pv h3g4 h1g1
472.204<--1:info depth 2 score mate 1 time 0 nodes 44 nps 0 pv a2a1
472.220<--1:info depth 3 score mate 1 time 0 nodes 62 nps 0 pv a2a1
472.220<--1:info depth 4 score mate 1 time 0 nodes 80 nps 0 pv a2a1
472.220<--1:info depth 5 score mate 1 time 0 nodes 98 nps 0 pv a2a1
[...]
472.876<--1:info depth 52 score mate 1 time 15 nodes 944 nps 62933 pv a2a1
472.891<--1:info depth 53 score mate 1 time 15 nodes 962 nps 64133 pv a2a1
472.906<--1:info depth 54 score mate 1 time 15 nodes 980 nps 65333 pv a2a1
472.923-->1:stop
472.923<--1:info depth 55 score mate 1 time 31 nodes 998 nps 32193 pv a2a1
472.938<--1:info depth 56 score mate 1 time 31 nodes 1016 nps 32774 pv a2a1
472.953<--1:info depth 57 score mate 1 time 31 nodes 1034 nps 33354 pv a2a1
[...]
473.657<--1:info depth 99 score mate 1 time 156 nodes 1790 nps 11474 pv a2a1
473.672<--1:info depth 100 score mate 1 time 156 nodes 1808 nps 11589 pv a2a1
473.689<--1:bestmove a2a1 ponder h1g1

As I am not having this problem with the average chess-position I assume that it is because of the many lines sent. Like in this position 100/1,5sec. In some other tests I saw that the command does eventually arrive, but it can take some seconds.

Where could this be coming from? Are there any solutions to the problem?

[sje]

Ideas:

1) Do not send any "info" lines to the interface during the first N seconds of an analysis. Many programs already work this way.

2) Keep a timer that ensures some minimum time separation between two outputs.

[hgm]

When I tried to build a WB version of Tsito-0.8.4 with gcc/Cygwin, the PeakNamedPipe did not seem to work at all, and the engine was just hanging, peeking the pipe forever while there was input pending.

I could only solve the problem by doing blocking input (losing the possibility to ponder).

[Edmund]

Thanks for the comments.

The problem was indeed that the io was overburdened.
What fixed it for me was to buffer all info-lines and send them together every 0,2-0,3 seconds. Furthermore I now changed my code so that only the most recent curmove and hashfull infos are sent.

[bob]

Thanks for the comments.

The problem was indeed that the io was overburdened.
What fixed it for me was to buffer all info-lines and send them together every 0,2-0,3 seconds. Furthermore I now changed my code so that only the most recent curmove and hashfull infos are sent.

I don't see how, in a pipe, one can become "overburdened". I use pipes all the time and the traffic they can handle is limited only by memory and processor speed, but _nothing_ ever goes lost...

[Edmund]

Crafty is not sending as many lines as Glass.

For one reason Crafty has the Noise option, furthermore according to the UCI-Protocol Glass sends current move info, Hashfull info, etc. (so in total easily > 30 lines per ply)

I never said anything went lost.
For example some times Arena sends 2 times "Stop" if the engine doesn't respond the first time. With my old implementation it recognized both Stops but both times very late.

[bob]

Crafty is not sending as many lines as Glass.

For one reason Crafty has the Noise option, furthermore according to the UCI-Protocol Glass sends current move info, Hashfull info, etc. (so in total easily > 30 lines per ply)

I never said anything went lost.
For example some times Arena sends 2 times "Stop" if the engine doesn't respond the first time. With my old implementation it recognized both Stops but both times very late.

I occasionally run with debugging on which sends a _ton_ of stuff to stdout, and xboard just merrily ignores it and keeps right on working... How does sending a lot of stuff _from_ your program make your receiving a stop command slow? Xboard uses two pipes and one won't affect how the other behaves...

[Edmund]

I occasionally run with debugging on which sends a _ton_ of stuff to stdout, and xboard just merrily ignores it and keeps right on working... How does sending a lot of stuff _from_ your program make your receiving a stop command slow? Xboard uses two pipes and one won't affect how the other behaves...

Could it be because of the commands I am using?
For sending I use printf() and for receiving I use gets();

I just checked the Crafty source code and you don't seem to use those.

[hgm]

Xboard uses two pipes and one won't affect how the other behaves...

But XBoard does not use PeekNamedPipe, of course... So this is not really relevant.

[Zach Wegner]

... for receiving I use gets();

Get rid of it immediately.

Thats not the problem though. I guess it's an OS issue