Running very fast games in xboard

[bob]

Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.

The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.

Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.

That's a good idea. In my case, using classical time control will work.

I'll do something like 40 moves per 15 seconds (if it's not too fast).

I would also suggest a "stress test" of something like 100 moves in 1 second, to make sure no program loses excessively due to being unable to move that quickly...

I play 1000 moves in 1 sec with Crafty for such testing to make sure nothing internal is broken.

[michiguel]

Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.

The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.

Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.

That's a good idea. In my case, using classical time control will work.

I'll do something like 40 moves per 15 seconds (if it's not too fast).

I would also suggest a "stress test" of something like 100 moves in 1 second, to make sure no program loses excessively due to being unable to move that quickly...

I play 1000 moves in 1 sec with Crafty for such testing to make sure nothing internal is broken.

I measured in my system (AMD 2x 4600, Ubuntu 7.04) that the average delay between xboard and the engines is ~8 ms. I expect at the speed you suggest to run the stress test to have some losses on time. If you do not see that many losses is because 100 moves or 1000 moves or 100000000000 moves per second basically "game in a second". It could also be that the delay is very dependent on the system and yours is much better (I would not be surprised).

Miguel

[michiguel]

Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.

The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.

Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.

That's a good idea. In my case, using classical time control will work.

I'll do something like 40 moves per 15 seconds (if it's not too fast).

I am doing right now 40 moves/20 seconds and it is fine.
make sure you run with -xanimate and 1) disable the screen saver and 2) close the folders that contain files that will be modified (for instance, folders that contain log files). In my case, Nautilus (gnome) updates the information of what the folders contain and chews some CPU time.

I estimate that running games 40 moves/4 s will still be ok but I have not tested it yet.

There were other suggestions such as running the engines with lower priority than xboard, but I have not tested that yet. There is a thread about it in winboard forum

http://www.open-aurec.com/wbforum/viewtopic.php?t=49855

Miguel

[bob]

Indeed, this is a problem with ultra-fast games: The incrtement gets lost in rounding. WB protocol does not allow decimals on the timing parameters.

The most practical solution is to not use incremental, but classical time control. Games on the average last 60 moves (and most engines assume this in allocating their time), so with 1:40+1 in practice you will be playing 60 moves in 160 seconds. So you could play 60/2:40 or 40/1:45 in stead. An alternative is to simply let the increment come to the engine as a (pleasant) surprise. Most of it will get lost in communication delays anyway, at this speed, so perhaps it is just as well that the engine does not count on it.

Usually adapting the engines is not an option. If it were, it would be best to forget about time, and implement the nps command in the engine to read its own node count in stead of the system clock. Then you are completely insensitive to any kind of delay, and could even play milli-second games.

That's a good idea. In my case, using classical time control will work.

I'll do something like 40 moves per 15 seconds (if it's not too fast).

I would also suggest a "stress test" of something like 100 moves in 1 second, to make sure no program loses excessively due to being unable to move that quickly...

I play 1000 moves in 1 sec with Crafty for such testing to make sure nothing internal is broken.

I measured in my system (AMD 2x 4600, Ubuntu 7.04) that the average delay between xboard and the engines is ~8 ms. I expect at the speed you suggest to run the stress test to have some losses on time. If you do not see that many losses is because 100 moves or 1000 moves or 100000000000 moves per second basically "game in a second". It could also be that the delay is very dependent on the system and yours is much better (I would not be surprised).

Miguel

When you go very fast, yes there will be some time losses. I will add that all my testing is on machines with more than one processor which helps the latency issue.

[cyberfish]

I took it one step further.

I compile a special xboard with essentially all calls to drawing functions commented out (except PV and score). Including the board (which could be achieved with the blindfold option), the clocks, and the changing of taskbar icon when switching sides to move (it made a big difference!).

[hgm]

I guess I could add this easily as a command-line option, if you tell me which parts of the code you commented out.

[cyberfish]

I did it a few weeks ago, and have no recollection of what I changed. I only commented out a few lines here and there, though, with a lot of trial and error (since I didn't try to understand the code structure), and a lot of search and replace kind of hacking.

[kranium]

i test using winboard and Marc Lacrosses Ultra-fast Wbx utility for ultra-fast games...15 seconds per game (no increment).

to eliminate time losses, setting /adjudicate LossThreshold=-200 in winboard.ini seems to work well

this method uses several utilities: delayexec.exe, delay.exe, and pv.exe (all freeware).
delay.exe replaces (DOS) pause command, allows you to specifiy the length in seconds (used to pause beginning of next game while winboard loads the next position)
pv.exe - kills any lingering processes

(example below: mfl-games.pgn is a pgn file with the 32 most frequent lines in chess, winboard.exe renamed wbx.exe, polyglot.exe renamed pg14.exe)

using the Ultra-Fast Wbx (gauntlet) executable, you create a (large) batch file something like this:

@echo off
Echo. *** Opponent number : 1 ***
Echo. startposition number : 1 ***
start /B delayexec "pv -cf wbx.exe > Nul" 34
start /MIN wbx.exe /debug /cp /mg={1} /lgf mfl-games.pgn /lgi 1 /ponderNextMove=false /sgf={.\cyclone_171-gauntlet.pgn} /fd={.\} /sd={.\} /scp={pg14.exe cyclone_171.ini} /fcp={pg14.exe rybka_3.ini} /tc={0:15} /mps={80} /inc={0} /td={2.0}
pv -e -x wbx.exe > nul
pv -kf delayexec.exe > nul
start pv -kf cyclone_171.exe > nul
start pv -kf rybka_3.exe > nul
start pv -kf pg14.exe > nul
delay 1 > nul
start /B delayexec "pv -cf wbx.exe > Nul" 34
start /MIN wbx.exe /debug /cp /mg={1} /lgf mfl-games.pgn /lgi 1 /ponderNextMove=false /sgf={.\cyclone_171-gauntlet.pgn} /fd={.\} /sd={.\} /scp={pg14.exe rybka_3.ini} /fcp={pg14.exe cyclone_171.ini} /tc={0:15} /mps={80} /inc={0} /td={2.0}
pv -e -x wbx.exe > nul
pv -kf delayexec.exe > nul
start pv -kf cyclone_171.exe > nul
start pv -kf rybka_3.exe > nul
start pv -kf pg14.exe > nul
delay 1 > nul
Echo. startposition number : 2 ***
start /B delayexec "pv -cf wbx.exe > Nul" 34
start /MIN wbx.exe /debug /cp /mg={1} /lgf mfl-games.pgn /lgi 2 /ponderNextMove=false /sgf={.\cyclone_171-gauntlet.pgn} /fd={.\} /sd={.\} /scp={pg14.exe cyclone_171.ini} /fcp={pg14.exe rybka_3.ini} /tc={0:15} /mps={80} /inc={0} /td={2.0}
pv -e -x wbx.exe > nul
pv -kf delayexec.exe > nul
start pv -kf cyclone_171.exe > nul
start pv -kf rybka_3.exe > nul
start pv -kf pg14.exe > nul
delay 1 > nul
start /B delayexec "pv -cf wbx.exe > Nul" 34
start /MIN wbx.exe /debug /cp /mg={1} /lgf mfl-games.pgn /lgi 2 /ponderNextMove=false /sgf={.\cyclone_171-gauntlet.pgn} /fd={.\} /sd={.\} /scp={pg14.exe rybka_3.ini} /fcp={pg14.exe cyclone_171.ini} /tc={0:15} /mps={80} /inc={0} /td={2.0}
pv -e -x wbx.exe > nul
pv -kf delayexec.exe > nul
start pv -kf cyclone_171.exe > nul
start pv -kf rybka_3.exe > nul
start pv -kf pg14.exe > nul
delay 1 > nul

etc., etc., etc.

i have excellent success with this method...running 1024 games in about 7 hours (with no time losses)..

http://users.skynet.be/mlcc/chessbazaar/mlmfl.html
http://chessbazaar.mylivepage.com/

Norm

[hgm]

With non-buggy engines that support ping (such as Polyglot ) it is often more efficient to run a match, reusing the engines. Then there is no issue of killing the engines, and you don't lose time in restarting the engines (and WinBoard) all the time. E.g.

winboard -fcp "PG cyclone_171.ini" -scp "PG rybka_3.ini" -mg 40 -lgf mfl-games -lgi -2 -reuse -reuse2

Only with engines that can hang the -reuse is better not used.

[kranium]

With non-buggy engines that support ping (such as Polyglot ) it is often more efficient to run a match, reusing the engines. Then there is no issue of killing the engines, and you don't lose time in restarting the engines (and WinBoard) all the time. E.g.

winboard -fcp "PG cyclone_171.ini" -scp "PG rybka_3.ini" -mg 40 -lgf mfl-games -lgi -2 -reuse -reuse2

Only with engines that can hang the -reuse is better not used.

yes, good point...
that's likely an improvement, (i'll test it next run...).

Norm