Explanation of the Cute Chess message 'connection stalls'

[Roland Chastain]

Hello! My chess program has a loop to evaluate material at two halfmoves depth. Recently, I introduced a recursive call, limited to one. Now, the tournament manager (Cute Chess Cli) says that the engine "connection stalls".

More exactly, that message comes when the number of moves increases (typically when the queen enters in action).

If I run my engine from the command prompt and enter the same position, I get a best move, after one good minute, but I get it.

So technically what does means that "connection stalls", and how to solve that? Should I break my loop in several parts?

A last thing: I can see in the task manager that the engine uses a constant small memory (1,3 Mb) and 25% of the processor.

Thank you for your attention.

[konsolas]

Your engine is probably crashing.

Try entering one of the positions where "the connection stalls" manually into your engine to see if it exits or does something strange.

[Roland Chastain]

Your engine is probably crashing.

Try entering one of the positions where "the connection stalls" manually into your engine to see if it exits or does something strange.

Thank you for your answer. I already did what you suggest, and it appears that the engine doesn't crash, since after a minute it returns its "best move".

If I run my engine from the command prompt and enter the same position, I get a best move, after one good minute, but I get it.

[JohnWoe]

Do you use -debug handle? It shows all commands sent to engines.
Is memory going higher? I know Sunfish ( python ) program seemed to play nicely and then everytime all of the sudden "connection stalls". I never investigated why.

[konsolas]

Do you implement UCI or Xboard?

Your engine needs to respond to the appropriate protocol's "ping" command.

In the case of UCI, you need to respond to "isready", even if you are searching.

[Roland Chastain]

@JohnWoe, konsolas

Thank you for your answers. I continue to search.

It's a UCI engine. The program is always able to answer.

For now I added a "no recursion" option, until I find a solution.

Maybe is it too much to compute all positions at five halfmoves depth? Should I ignore some move sequences?

Here is the position which makes the problem happen, and the number of positions at depth 5 for that position:

Code: Select all

C:\Roland\pascal\echecs\smirf-uci>smirf32
position fen qr3b2/n1pk4/Qp2rQ2/1P2P3/8/1pN5/6R1/2K1R3 w - - 0 47
perft 5
perft(5) = 98994285

If I start the engine from the command prompt, it returns its best move after one minute and an half.

[elcabesa]

I haven't understood what you have implemented and how you use cutechess

cutechess reports "connection stalls" when the engine doesn't reply wuth the expected messages to stop, or uci (I suppose).

if you use cutechess with tournament time control and your engine search at depth 5 and after a minute report the bestmove, it could happen that cutechess has calculated that you have finished search time, it send "stop" command but the engine don't reply with bestmove.

Is this the scenario? can you explain better, and tell what command line you use for cutechess?

[Roland Chastain]

cutechess reports "connection stalls" when the engine doesn't reply with the expected messages to stop, or uci (I suppose).

if you use cutechess with tournament time control and your engine search at depth 5 and after a minute report the bestmove, it could happen that cutechess has calculated that you have finished search time, it send "stop" command but the engine don't reply with bestmove.

Is this the scenario? can you explain better, and tell what command line you use for cutechess?

Thank you for your answer. Yes, this seems to be the scenario. Here is my command:

Code: Select all

%cutechess% -rounds 20 ^
-engine conf="Alouette 0.0.6" ^
-engine conf="Alouette 0.0.5" ^
-engine conf="Belofte 0.9.0" ^
-engine conf="Pulsar 2009 9a" ^
-pgnout %~dpn0.pgn ^
-each tc=40/40 ^
-wait 500 | %tee% %~dpn0.log

[elcabesa]

if your engine search at fixed depth and doesn't answer until it hs finished you can try a combination of those options with cutechess:

depth=plies
Set the search depth limit.

st=n Set the time limit for each move to n seconds. This option
cannot be used in combination with the tc option.

e.g.

Code: Select all

%cutechess% -rounds 20 ^
-engine conf="Alouette 0.0.6" ^
-engine conf="Alouette 0.0.5" ^
-engine conf="Belofte 0.9.0" ^
-engine conf="Pulsar 2009 9a" ^
-pgnout %~dpn0.pgn ^
-each st=900 depth=5 ^
-wait 500 | %tee% %~dpn0.log

[Ras]

When I look at alouette.pas, the parser for the "go" command is not really implementing the UCI spec. The order of arguments is not specified, but you rely on it in utils.pas. Also, the case where wtime, btime, winc, binc AND movestogo is given seems to be missing.

I'd suggest that you do a WordPresent or so on every possible argument, and if it's present, get its position dynamically, and the following argument then must be the integer parameter. At the end, figure out which configuration it is.

Also, the UCI parser doesn't contain the 'stop' command so that the engine can't possibly react to it. Yes, 'stop' needs to be evaluated while the engine is calculating its move. 'isready' the same. I'm not good enough at Pascal to see whether you're running the UCI parser and engine calculator in different threads so that the move calculation won't block the evaluation of UCI input.