How to solve Arena's time issues

[michiguel]

If an engine sends too much information, Arena 2.0.1 processes that info slowly and punishes the engine for it. So, refrain to send info currmove etc. etc., at least until several ply iterations. It is pointless to do it anyway. Do not spam the GUI with info before 6-8 interations have been reached.

Also, as a user, do not use piece sliding! That is true for any GUI! (even Winboard)

Following this guidelines with the new Gaviota version (to be released), I can play fast games and the lag that Gaviota measures is only ~10 ms.

I have the theory that SF has problems because being a very fast and selective engine, ends up going through many iterations and sending to much stuff, which spams the GUI. Maybe there is a solution along these lines.

Bottom line, as an author: control the output, and as a user: do not slide the pieces.

It took me a while to figure out why Gaviota UCI was slower than Gaviota Winboard in Arena! (Thanks to Dann Corbit for this finding). Incidentally, this effect is worse in Windows 7 than XP (that is why I missed it).

Miguel
PS: Arena 2.0.6 seems to be significantly better at this!

[luisrodg]

What do you mean by not sliding the pieces?

I recently put win7 on my laptop and have noticed extreme sluggishness after inputting a move into any GUI (fritz12 and arena2.0.1)

[TonyJH]

I think by sliding pieces he's referring to the option to animate moving pieces (showing the piece sliding when a move is made).
In WinBoard there is a checkbox for "Animate Moving" in the general options.
I agree it's a good idea to disable this for engine games.

[hgm]

In WinBoard completing the move animation has priority over accepting the move of the side who's clcok is running. So there is a certain minimum time needed for each move. Although animating a move takes only a fraction of a second (in fact this can be configured in the ini file; you can make the animation progress at snail's pace, if you want), for 1-min games the default setting can become a problem.

This behavior is the intended one, however, and if the TC is such that you cannot afford it, just switch it off. One of the reasons for doing it this way is when you are watching engine games, and the engines suddenly start moving instantly, because they are in book or play the mate from their hash table, the user will still be able to see what happens.

[Volker Annuss]

If an engine sends too much information, Arena 2.0.1 processes that info slowly and punishes the engine for it. So, refrain to send info currmove etc. etc., at least until several ply iterations. It is pointless to do it anyway. Do not spam the GUI with info before 6-8 interations have been reached.

Also, as a user, do not use piece sliding! That is true for any GUI! (even Winboard)

Following this guidelines with the new Gaviota version (to be released), I can play fast games and the lag that Gaviota measures is only ~10 ms.

I have the theory that SF has problems because being a very fast and selective engine, ends up going through many iterations and sending to much stuff, which spams the GUI. Maybe there is a solution along these lines.

Bottom line, as an author: control the output, and as a user: do not slide the pieces.

It took me a while to figure out why Gaviota UCI was slower than Gaviota Winboard in Arena! (Thanks to Dann Corbit for this finding). Incidentally, this effect is worse in Windows 7 than XP (that is why I missed it).

I use the internal UCI Filter in Arena which soves most of the problems.
Engines/Manage/Options/Always use UCI filter

For older Arena versions I made my own UCI Filter that filters out most of the spam that engines send to Arena in the first second. It is many years old but still available.

Arena 2.0.6 seems to be significantly better at this!

Do you have a copy?

[Ferdy]

If an engine sends too much information, Arena 2.0.1 processes that info slowly and punishes the engine for it. So, refrain to send info currmove etc. etc., at least until several ply iterations. It is pointless to do it anyway. Do not spam the GUI with info before 6-8 interations have been reached.

Also, as a user, do not use piece sliding! That is true for any GUI! (even Winboard)

Following this guidelines with the new Gaviota version (to be released), I can play fast games and the lag that Gaviota measures is only ~10 ms.

I have the theory that SF has problems because being a very fast and selective engine, ends up going through many iterations and sending to much stuff, which spams the GUI. Maybe there is a solution along these lines.

Bottom line, as an author: control the output, and as a user: do not slide the pieces.

It took me a while to figure out why Gaviota UCI was slower than Gaviota Winboard in Arena! (Thanks to Dann Corbit for this finding). Incidentally, this effect is worse in Windows 7 than XP (that is why I missed it).

Miguel
PS: Arena 2.0.6 seems to be significantly better at this!

Thanks for this info. Deuterium by default uses a time buffer of 20 milli sec per move to solve loss on time.

I plan of adding Gui and Time_Buffer options in initialization file to fit Gui behaviours.

[Michel]

One of the reasons for doing it this way is when you are watching engine games, and the engines suddenly start moving instantly, because they are in book or play the mate from their hash table, the user will still be able to see what happens.

But in principle xboard could simply wait with forwarding the move to
the other engine until the animation is complete no?

[michiguel]

If an engine sends too much information, Arena 2.0.1 processes that info slowly and punishes the engine for it. So, refrain to send info currmove etc. etc., at least until several ply iterations. It is pointless to do it anyway. Do not spam the GUI with info before 6-8 interations have been reached.

Also, as a user, do not use piece sliding! That is true for any GUI! (even Winboard)

Following this guidelines with the new Gaviota version (to be released), I can play fast games and the lag that Gaviota measures is only ~10 ms.

I have the theory that SF has problems because being a very fast and selective engine, ends up going through many iterations and sending to much stuff, which spams the GUI. Maybe there is a solution along these lines.

Bottom line, as an author: control the output, and as a user: do not slide the pieces.

It took me a while to figure out why Gaviota UCI was slower than Gaviota Winboard in Arena! (Thanks to Dann Corbit for this finding). Incidentally, this effect is worse in Windows 7 than XP (that is why I missed it).

I use the internal UCI Filter in Arena which soves most of the problems.
Engines/Manage/Options/Always use UCI filter

Thanks, I am a newbie regarding Arena. I wonder how many testers are aware of that?

For older Arena versions I made my own UCI Filter that filters out most of the spam that engines send to Arena in the first second. It is many years old but still available.

Arena 2.0.6 seems to be significantly better at this!

Do you have a copy?

I was given a copy to beta test the tablebases.

Anyway, I was testing gaviota against Hermann, which handles this issues flawlessly. Hermann knows very well when and when not to send info.
Hermann is one of my favorite engines to test Gaviota (mostly in Linux using wine). Never gave me a problem.

Miguel

[hgm]

But in principle xboard could simply wait with forwarding the move to
the other engine until the animation is complete no?

In local play you could do this. But in ICS play the ICS keeps the time, and the clock would always be running.

[bob]

If an engine sends too much information, Arena 2.0.1 processes that info slowly and punishes the engine for it. So, refrain to send info currmove etc. etc., at least until several ply iterations. It is pointless to do it anyway. Do not spam the GUI with info before 6-8 interations have been reached.

Also, as a user, do not use piece sliding! That is true for any GUI! (even Winboard)

Following this guidelines with the new Gaviota version (to be released), I can play fast games and the lag that Gaviota measures is only ~10 ms.

I have the theory that SF has problems because being a very fast and selective engine, ends up going through many iterations and sending to much stuff, which spams the GUI. Maybe there is a solution along these lines.

Bottom line, as an author: control the output, and as a user: do not slide the pieces.

It took me a while to figure out why Gaviota UCI was slower than Gaviota Winboard in Arena! (Thanks to Dann Corbit for this finding). Incidentally, this effect is worse in Windows 7 than XP (that is why I missed it).

I use the internal UCI Filter in Arena which soves most of the problems.
Engines/Manage/Options/Always use UCI filter

Thanks, I am a newbie regarding Arena. I wonder how many testers are aware of that?

For older Arena versions I made my own UCI Filter that filters out most of the spam that engines send to Arena in the first second. It is many years old but still available.

Arena 2.0.6 seems to be significantly better at this!

Do you have a copy?

I was given a copy to beta test the tablebases.

Anyway, I was testing gaviota against Hermann, which handles this issues flawlessly. Hermann knows very well when and when not to send info.
Hermann is one of my favorite engines to test Gaviota (mostly in Linux using wine). Never gave me a problem.

Miguel

I don't think you have gotten to the bottom of this yet. Frank just sent me a log where Crafty lost on time. Here is the relevant excerpt:

Code: Select all

White(39): time 2251
time remaining:  22.51 (Crafty).
White(39): otim 2648
time remaining:  26.48 (opponent).
White(39): Bf1
              time used:  32.30
              time surplus   0.00  time limit 11.25 (+0.00) (11.25)
              depth   time  score   variation (1)
               10     0.11   0.61   39. ... Nd7 40. Qb5 Qc7 41. Kg2 h4
                                    42. g4 Nc5 43. Nb6 Bf6 44. Nxc8 Qxc8

<snip>

              time=11.94  mat=0  n=30887872  fh=93%  nps=2.6M
              extensions=193K qchecks=552K reduced=4.5M pruned=8.7M
              predicted=18  evals=11.3M  50move=2  EGTBprobes=0  hits=0
              SMP->  splits=0  aborts=0  data=0/65536  elap=11.94
Black&#40;39&#41;&#58; Nd7
              time used&#58;  11.94

&#91;snip&#93;

White&#40;40&#41;&#58; time 46
time remaining&#58;   0.46 &#40;Crafty&#41;.
White&#40;40&#41;&#58; otim 62363
time remaining&#58;  10&#58;23 &#40;opponent&#41;.
White&#40;40&#41;&#58; h4

If you follow that, at move 39 arena says "you have 22+ seconds left". Crafty searched for 11.94 seconds (time control happens at move 40 here). It makes a move. Opponent moves, arena says "you have 0.46 seconds left." How?

22 - 12 = 10, not 0.5...

I do not run arena, but am going to download it and investigate. I verified that Crafty is sending _no_ output except when arena sends a ".". Otherwise it sends "move xyz" and is silent, so it isn't a SPAM issue at all. Just vanishing seconds...

More once I figure this one out... I do know that I have not lost a game on time using my (working) referee program on the cluster over hundreds of millions of games, and I have not lost an ICS game on time except when I broke the program and caused it to hang or crash...

In the words of Sherlock Holmes, "The game is afoot..."