|
|
FAQ for Rybka's Parameters
Can you explain the parameters of Rybka 2 to me?
Engine parameters:
1) Display Draw Scores: if false, then evaluation scores between -0.03 and +0.03 are rounded to those boundary values during game play. This prevents user interfaces from adjudicating games as draws. This engine parameter has no effect in infinite analysis mode.
2) Preserve Analysis: if true, then deep entries from the transposition table are preserved during analysis. This is useful when analysing a game by moving backwards through the moves. The conclusions of the positions further along in the game (or variation) are kept and used when analyzing positions which occurred earlier. The transposition table should occasionally be cleared when this option is set.
3) Contempt: used to take drastic measures to avoid draws against weaker players. A positive contempt indicates that draws are to be avoided, while a negative contempt will cause Rybka to seek draws.
4) Outlook: more optimistic settings cause Rybka to spend more time investigating improbable but potentially devastating tactical lines. More pessimistic settings instruct Rybka to not go hunting for such strikes, and rather to concentrate on playing sound positional chess.
5) Rate of Play: controls Rybka's time management during games. Note that Rybka already plays relatively quickly by default.
6) Time Usage: controls whether Rybka's time allocation is varied. By default, Rybka will spend significantly more time on more interesting positions. The 'Constant' option instructs Rybka to always take the same amount of time for each move.
7) Emergency Time Buffer: Rybka always keeps at least this much time on her clock.
8) Win Percentage to Hash Usage: False by default; if true, then the estimated winning percentage for the current position (from the white point of view) is sent as the "hashfull" value. Some user interfaces (e.g. Arena, Shredder GUI) display this value somewhere in the engine pane.
Engine parameters for system problems:
Overview:
On some systems, the communication between the engine and the user interface becomes sluggish or otherwise problematic. This results in a slow updating of the user's screen, the failure to move in time during game play, and, in some cases, the complete loss of information from the engine <-> user interface communication channel.
These problems appear to be more serious on multi-processor systems where all processes are used at full capacity.
The following parameters work around these issues. The default settings should minimize such problems. Expert users can tinker with the other parameters to obtain optimal performance for their particular systems.
9) Engine Priority: Rybka always sets her own priority, independent of the priority with which she is started by the user interface. This parameter controls that priority. 'Normal' indicates that the main Rybka process, as well as all Rybka child processes (in multi-processor mode), are run at normal priority. 'Low' indicates that all Rybka processes are run at low priority. The default 'NormalAndLow' indicates that the main Rybka process is run at normal priority, while any child processes (in multi-processor mode) are run at low priority, leaving more system resources to the user interface.
10) Compensate Lost Time: Consider the following case: Rybka starts a search with 30 seconds on her clock (no increment). She searches for two seconds and plays her move. When she is instructed to perform her next search, she is told that only 27 seconds (rather than the expected 28) exist on the clock. This 1 second is called 'lost time', and when this parameter is set to true, Rybka will assume that she will lose the same amount of time during the next search and adjusts her time allocation accordingly. (Note: this parameter has the adverse effect that it can mask some serious problems with your system or interface.)
11) Server Buffer: In some cases, online chess servers will not report the time available to the engine truthfully. This typically only becomes significant in absurdly long games (ie 100 moves and above). When this option is checked, Rybka assumes that the actual time left is less than what is reported by the interface.
12) NalimovUsage: For some customers, the Nalimov tablebase support in Rybka 2 can cause various problems. A new NalimovUsage parameter value of Never has been added, and will be set as the default until I am sure that these issues are 100% resolved.
It is of course recommended that tablebases be set up in the GUI, and that the GUI be allowed to take over in tablebase positions.
13) Max CPUs: This puts an upper bound on the number of cores used by Rybka. If it is left at the default value, Rybka will start exactly one process for each core in your system.
Users can use this option to keep CPU time available for other, non-Rybka processes.
14) Display Current Move: True by default; if false, Rybka will not send any information about the move currently being searched. This is Aaron Gordon's fix, you can read about it in the Rybka forum. I use Chess Assistant 9 for my testing and have never noticed any slowdown or seen any suspicious performance, but there is no reason to not give users the chance to experiment with this.
15) Display PV Tips: False by default; if true, Rybka will report the longest possible principal variation. The tips tend to be low-quality and can even have blunders, but as with "Display Current Move", I see no reason to not give users the chance to configure this.
16) CPU Usage: 100 by default. Lower values cause Rybka to 'sleep' in mid-search and allow other processes on the machine to take care of their business. This provides an alternative to the priority mechanism provided by windows. It's not the standard windows method for dealing with multi-tasking issues, but users who have system or interface issues may consider experimenting with this setting.
The following parameters exist only in older versions of Rybka:
a) Output: controls how much information the engine reports to the interface. Verbose reports large amounts of information, Sparse limits the output to minimal amounts.
b) IO Supplementation: When checked, Rybka will re-send her move if she has already sent her move once and the user interface has ignored it for at least 500 milliseconds. (This is for cases where the communication between the engine and interface disappears completely.)
What about the "UCI_..." options?
If you can see those options, this means that the graphical interface you use doesn't support all of the UCI or UCI 2 options. I would suggest to simply ignore those parameters.
Which configuration is the best?
With the default configuration Rybka plays already at full strength, but if you are an advanced user, you can toy around with some parameters like "Outlook" and "Rate of play", if you want to optimize the configuration.
If you have further questions, we invite you to visit the Rybka forum.
|
|
|
