UCI protocol timing

[stegemma]

Developing my interface I'm trying to understand UCI protocol. As far as I know, it seems that it is somehow "stateless", because you have to always pass to the engine all the moves, with the "position" command. That sounds very strange, for those coming from xBoard/WinBoard protocol... but it works now. What I'm not sure to handle correctly is the timing part of the "go" command. For sample, if I wish a game of 30 seconds I pass this command to the engine:

Code: Select all

go wtime 300000 btime 300000 winc 0 binc 0

But the engine seems to think infinite and loose do to timeout.

What I'm doing wrong?

[AlvaroBegue]

I just tried with my engine and with stockfish and they both replied after a few seconds of thinking.

uci
id name Stockfish 6 64 BMI2
id author Tord Romstad, Marco Costalba and Joona Kiiski

option name Write Debug Log type check default false
[...]
uciok
position startpos
go wtime 300000 btime 300000 winc 0 binc 0
info depth 1 seldepth 1 multipv 1 score cp 84 nodes 21 nps 3500 tbhits 0 time 6 pv e2e4
info depth 2 seldepth 2 multipv 1 score cp 82 nodes 62 nps 10333 tbhits 0 time 6 pv e2e4 b7b6
[...]
info depth 22 seldepth 28 multipv 1 score cp 20 nodes 19378949 nps 2294452 tbhits 0 time 8446 pv e2e4 e7e5 g1f3 g8f6 f3e5 d7d6 e5f3 f6e4 d1e2 d8e7 d2d3 e4f6 c1d2 b8c6 b1c3 c8e6 e1c1 e8c8 c1b1 c8b8 d3d4 h7h6 a2a3 a7a6 d1e1 d6d5 d2f4
bestmove e2e4 ponder e7e5

[stegemma]

Thanks, so the command looks right... I should investigate further...

[petero2]

I don't know if this is related to your problem or just a simple typo, but in the text you wrote 30 seconds and in the go command 300 seconds, since time is there measured in milliseconds.

[stegemma]

It was a typo, the interface sends the time in thousands of seconds. The software involves different threads, pipes mutex and so on... so the error could be almost everywhere.

Thanks.

[Sven]

The software involves different threads, pipes mutex and so on... so the error could be almost everywhere.

I would still expect the problem to be closely related to your UCI implementation of time control, assuming you already had a working WB interface.

EDIT: I would start by testing with very small TC values to find out whether your engine will really think "infinitely long". Next might be to check how you determine a timeout, and how the data needed for this calculation make their way from the UCI interface to your search. I would also print all time control parameters, including both the original input parameters as well as values derived from it, immediately before starting the search. Usually this should already be sufficient to spot the error.

[stegemma]

The software involves different threads, pipes mutex and so on... so the error could be almost everywhere.

I would still expect the problem to be closely related to your UCI implementation of time control, assuming you already had a working WB interface.

EDIT: I would start by testing with very small TC values to find out whether your engine will really think "infinitely long". Next might be to check how you determine a timeout, and how the data needed for this calculation make their way from the UCI interface to your search. I would also print all time control parameters, including both the original input parameters as well as values derived from it, immediately before starting the search. Usually this should already be sufficient to spot the error.

Thanks for the hint! it was a very stupid error, some "cut&paste-magic-mistake":

bad code:

Code: Select all

int clsEngineInterface::GetInc()
{
	return ms;
}

right code:

Code: Select all

int clsEngineInterface::GetInc()
{
	return msInc;
}

And finally it seems to works... until the next bug!