uci & time management

[flok]

Hi,

I'm trying to let an UCI chess engine think for a fixed amound of time.
For that I'm telling it:

go wtime 750 movestogo 1

(or btime).
This works arasan, bikjump and stockfish but other engines like fruit, glaurung and toga 2 behave strangely. fruit for example uses only +/- 25ms, glaurung only 400ms and toga 2 uses 30ms.

If I then use:

go movetime 750

then it becomes even more strange: fruit then uses 850ms, glaurung uses 950ms and toga2 uses 870ms! That's way more than I asked them to use.

Has anyone any ideas regarding this? Tips, hints, anything?

I am by the way also looking for other UCI chess engines that run on an arm/linux platform (most opensource engines are rather difficult to get compiled: no makefile or using asm (problematig on an arm) or dependencies on windows specifics).

[Daniel Mehrmann]

Hi,

I'm trying to let an UCI chess engine think for a fixed amound of time.
For that I'm telling it:

go wtime 750 movestogo 1

(or btime).
This works arasan, bikjump and stockfish but other engines like fruit, glaurung and toga 2 behave strangely. fruit for example uses only +/- 25ms, glaurung only 400ms and toga 2 uses 30ms.

Well, Fruit divided any "time" input by 1000ms. But it's double. Second step is a reserved time buffer of 1000ms...

Well, that's it's a good point anyway. That should be fixed.

If I then use:

go movetime 750

then it becomes even more strange: fruit then uses 850ms, glaurung uses 950ms and toga2 uses 870ms! That's way more than I asked them to use.

Fruit will use the max time for sure. If Fruit use a tiny bit more, it depends on the polling stuff (time check) and OS scheudler. So, everything is fine here.

Regards
Daniel

[flok]

(fruit being too conservative with time)

Well, Fruit divided any "time" input by 1000ms. But it's double. Second step is a reserved time buffer of 1000ms...

Argh and it is opensource, I wonder why I did not looked in the code myself!
Anyway, I have adapted it and now it indeed uses almost all allocated time. Nice!

If I then use:

go movetime 750

then it becomes even more strange: fruit then uses 850ms, glaurung uses 950ms and toga2 uses 870ms! That's way more than I asked them to use.

Fruit will use the max time for sure. If Fruit use a tiny bit more, it depends on the polling stuff (time check) and OS scheudler. So, everything is fine here.[/quote]

Odd because some of the other programs I mentioned do this fine. Also 100ms is a bit much for scheduling overhead I think.

But all in all: thanks for putting me on track![/quote]

[hgm]

If Fruit use a tiny bit more, it depends on the polling stuff (time check) and OS scheudler. So, everything is fine here.

Except of course that it would have been flagged in that case... The zero you get for being a tiny bit over time is just as fat as the one you get when you don't move at all. A forfeit is a forfeit.

[Daniel Mehrmann]

If Fruit use a tiny bit more, it depends on the polling stuff (time check) and OS scheudler. So, everything is fine here.

Except of course that it would have been flagged in that case... The zero you get for being a tiny bit over time is just as fat as the one you get when you don't move at all. A forfeit is a forfeit.

Well, if you take "tournament" conditions - You're right of course!

But i think the "movetime" feature hasn't that goal.
From the "technical" point of view erverything is correct and I guess a lot of engines doing it on that way.