RYBKA
 ••• HomeRybka engineFAQ for v 2.x
 
Rybka engine
FAQ
Demo version
Purchase Rybka
Rybka 4 book
Rybka 3 user area
FAQ for v 2.x
Home
one


FAQ for Rybka 2'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.


Rybka 2.3

This version is the last upgrade for the Rybka 2 series.

Algorithmic Improvements

As always, the main focus of the work since the last release has been the search and evaluation heuristics. I believe that this Rybka version will show improved behavior in many different types of positions.

I'd like to especially thank IM Larry Kaufman for his work in helping to improve Rybka's behavior in exchanging pieces and pawns. Larry has now done a tremendous amount of work on this complex topic and you'll see the fruits of it here in the LK version of Rybka 2.3 as well as hopefully in Rybka 3.

Playing Strength

The playing strength seems modestly improved since the last version. For what it's worth, I ran a blitz match (1' + 1") between Rybka 2.3 and Rybka 2.2n2 and got a result of: +245 =607 -193 (52.5%, +17 Elo).

Randomizer

There is one interesting new feature, which we will call the "randomizer". The idea is to allow a user to play many games from a single starting position in order to collect statistics about that position. A randomized Rybka will keep track of the previous games and not repeat previous variations, so that a match between two randomized Rybkas will systematically explore the space of variations from the starting position.

The following are steps for playing a match between two randomized Rybkas from some starting position:

1) Create two separate directories (anywhere on your machine).
2) Put a copy of "Rybka v2.3.x64.exe" in each directory. (Or "Rybka v2.3.w32.exe", heaven forbid.)
3) Create a text file named rybka.config in each directory, and add the single line "randomize=10" to this file. (This value 10 is a centipawn threshold margin for candidate moves, more below.)
4) Install the first of the two Rybkas in your interface.
5) Rename this first Rybka to something like "Rybka 2.3.1 (random)"
-- Note: for the Fritz interface, this must be done manually by editing the appropriate .uci file. You'll need to go to the "Engines" folder for this interface, find the newly-created "Rybka 2.3.uci" file, and rename both the file as well as the "Name=xxx" line inside the file. Most interfaces allow name changes to be done inside the interface.
6) Install the second Rybka in your interface
7) Rename it (as in step 5)
8) Create a .pgn file with the position you would like to test. For example, like this:

[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "*"]
[ECO "E32"]
[PlyCount "20"]

1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. Qc2 O-O 5. a3 Bxc3+ 6. Qxc3 d6 7. f3 d5 8. Bg5 Nbd7 9. e3 Re8 10. Ne2 b6 {#} *

9) Set up an engine match between the two newly-installed random Rybkas from this position. In the Fritz GUI, this is done via "new->engine match", using the "Openings DB" button to select the file created in step 8.
10) Make sure that you ask for many games. (ie. "# of games"). I suggest somewhere around 500.
11) I can suggest very fast games, for example use a fixed-depth of 6, 7 or 8.
12) Once the match is finished, you will have a set of games. This is useful for two reasons:

a) The statistics on this set of games are in my experience a fairly reliable indicator of the evaluation of the position.
b) These games can be imported into your interface's native tree format for browsing. In the Fritz GUI, this is done via "Edit->Openings Book->Import Games".

Alternative operation methods:

1) You can increase or decrease the breadth of the alternatives which are explored during the play by increasing or decreasing the margin in the "rybka.config" file.
2) You can run many positions at once by including multiple positions in the input .pgn file. Just make sure that you are selecting the proper number of games to cover all of the positions.
3) You can have a randomized rybka play against a non-randomized Rybka. The non-randomized Rybka will of course always choose the best moves, while the randomized Rybka will vary her play in order to cover all of the variations.

One final note:

A randomized Ryka remembers the previously-played positions from the moment she is loaded to the moment that she is unloaded. If you would like to repeat a previous match from the beginning without attempting to skip already-played variations, you should completely unload the version from the interface.

Rybka Forum

If you'd like to learn more about how to use the randomizer or interpret the results, or about any other part of Rybka, you're welcome to join us for discussion on our forum: www.rybkaforum.net

Next Steps

Our next steps will be to:

1) Port Rybka to various mobile devices. This is imminent, ie. February or March 2007.
2) Rybka 3 for PC. No date is yet set, but it should be sometime later this year.

And, finally - thanks for being a Rybka customer!

Vasik Rajlich


FAQ for Rybka 2.0-2.2n2

Rybka 2.0 Beta (multi-processor only)
June 10, 2006

Rybka 2.0 Beta is the first release from the Rybka 2 series. Customers who purchase this Rybka version will receive free upgrades until February 12, 2007.

The full Rybka 2 schedule is as follows:

June 10: Rybka 2.0 Beta (multi-processor only)
July 15: Rybka 2.1 (multi-processor and single-processor)
Nov. 15: Rybka 2.2 (multi-processor and single-processor)
Feb. 12: Rybka 2.3 (multi-processor and single-processor)

Owners of single-processor machines should wait until July 15 to make their purchase.

FAQ

What is the difference between the single-processor and the multi-processor versions?
None. (Except for the utilization of the additional processors.)

I have a dual-core machine. Do I need the multi-processor version?
If you want Rybka to take advantage of the second core, the answer is yes. You can of course run the single-processor version as well, but in this case you won't exploit the full power of your hardware.

I am using Rybka 1.2. Should I upgrade to Rybka 2.0 Beta?
Only if you have a system with multiple processors and are comfortable using our software in the early stages of its life cycle. Otherwise, please wait until the Rybka 2.1 release on July 15.

How much does Rybka 2 cost?
The multi-processor version costs 59 Euro. The single-processor version will cost 34 Euro.

Why is this version labeled as a Beta?
This is the first public release of the multi-processor version of Rybka. It's inevitable that some issues will pop up. If you prefer to work only with mature, 100% reliable software, we suggest that you wait until July 15 for Rybka 2.1.

Aside from multi-processor support, what else is improved since Rybka 1.2?
Very little. Some smaller bugs were fixed, and a few minor improvements were made. The playing strength increase on one-processor machines is probably in the range of 5 to 10 rating points.

I have only a single-processor system. What should I do?
You should wait until July 15, when Rybka 2.1 is released.

What can I expect from Rybka 2.1?
I plan to continue the work on the multi-processor implementation, and to also finally return to work on the evaluation and search.

I am a tester. Should I include Rybka 2.0 Beta on my rating list?
I will be honored if you do so, but please be warned that the multi-processor implementation is still undergoing changes. It is very likely that there will be a few additional releases in June which impact the multi-processing performance. If you prefer to test only major versions, it may make sense to wait until July 15 - by this time, the dust should be settled.

I have an AMD dual-core system. Will this benefit from the multi-processor support?
Yes. From a software point of view, multi-core systems behave (roughly) the same as multi-processor systems, and benefit (roughly) the same amount from the additional cores. I use the terms "core" and "processor" interchangeably throughout this document.

How much stronger is Rybka on multi-processor systems?
As a first approximation, every time you double the number of processors, the engine level increases by approximately 50 rating points. For an elaboration, see the section below.

When exactly can I buy this version?
The version itself will be released on midnight, June 10. The various ordering options are still being set up (on this day) and some of them may not be functional until a day or two after June 10. If you were a Rybka 1 customer, you can send me an email with your intention to pay and I will send you the version. Non-Rybka 1 customers may need to be a bit patient.

How will I receive my copy of Rybka 2.0 Beta, as well as the free upgrades to Rybka 2.1, Rybka 2.2 and Rybka 2.3?
You will receive download links via email. Please note that we will not be using a yahoo group this time, as we had with Rybka 1.

Is there any copy protection?
Not for the Rybka 2.0 Beta version. Personally, I think it's a waste of everybody's time, but I reserve the right to change this policy and add copy protection to later releases from the Rybka 2 series. (The reasons for this will be clear later.)

Multi-processing Implementation

If you are a simple user, then take the Rybka 2.0 Beta executable, install it as you would install any other UCI engine, and use it as you would use any other UCI engine. The utilization of the additional processors is seamless.
In my experience, owners of multi-core systems can be quite serious about hardware and performance. If this describes you, and you want to understand a bit better what happens under the hood and what the performance implications are, then read the following FAQ.

I'll start with a few softballs and go from there ..

Is multi-processing easy or hard?
Getting a multi-processor version of a chess engine running with a decent speedup is not that hard. Getting past various impediments to performance is potentially an endless job.

Is multi-processing performance relevant?
There are two points to make here.
One is that by the end of 2007, experts project that as many as 70% of new computer systems will have more than one core. This is the obvious point.
The less obvious point is that flaws in a parallel implementation magnify exponentially as the number of cores in the system increases. When running on a two-core system, even a pretty weak implementation is not that far from the optimal. As the number of cores increases, a good parallel implementation diverges further from a bad one. More on this below.

What speedup do you get from your multi-processor implementation?
Ok, this is where the fun begins. The implementation which is released as the default in Rybka 2.0 Beta gives the following speedups:

2 Processors: 1.7
4 Processors: 2.8
8 Processors: 4.4

Here, speedup is defined as the effective increase in speed. In other words, if you play a match between Rybka on two processors and Rybka on one processor, and give the one-processor version 1.7 times more time (with ponder off), the match will be equal.

Since the released implementation is fairly safe, there is not really much doubt about the above values. They are certainly not inaccurate by more than 5% or so. In the case of more ambitious implementations, where the shape of the search tree of the multi-processor version starts to differ more significantly from the shape of the search tree of the single-processor version, giving true effective speedups is trickier. In such cases, it is probably necessary to measure actual playing strength to be really sure.

How much better would a perfect multi-processing implementation perform compared to the above values?
Here, "perfect" is defined as an implementation which gives a speedup of 2.0 on two cores, 4.0 on four cores, etc. It is (probably) not quite possible to achieve this. The question is relevant for us because this represents an upper bound on potential multi-processing performance.

The following table shows how actual Rybka performance diverges from this theoretical upper bound as the number of cores increase.

# of cores Actual speedup Speedup upper bound Upper bound / Actual Elo difference between upper bound and actual
2 1.7 2.0 1.17 ~11.9
4 2.8 4.0 1.42 ~29.4
8 4.4 8.0 1.81 ~56.7

The values from the last column were computed using the formula of ((upper bound speedup) / (Actual speedup) - 1.0) * 70. In other words, they are based on the assumption that a doubling in speed gives 70 rating points.
The point is that for the two-core systems which are common today, the multi-processing implementation in Rybka 2.0 Beta is already close enough to perfect that more work would not be productive. For bigger systems, however, as we are likely to see in the future, further improvement will pay off.

So, are you planning to improve the implementation?
Yes. In fact, the work is already continuing - the released implementation is simply the safest one I have at the moment. If you have a system with 4 or more cores, you can still expect improved performance.

Why are the nodes per second rates of the multi-processor version so low?
The nodes searched by the child processes are not counted. Anyway, node counts do not reflect true multi-processing efficiency and are not relevant to measuring multi-processor performance.

Why are you using processes rather than threads?
I am still experimenting with this, but for now, it is safer, especially when using NUMA (non-uniform memory architecture) systems. Processes do their own memory allocation, and we are guaranteed that the system allocates this memory in the correct (local) segment.

One nice consequence of this is that you can observe Rybka using various system measurements tools such as the task manager.

When I allocate a hash size of 512 MB, the task manager shows that each of the Rybka processes is using 512 MB. Is this correct?
No - this is a bug (or odd feature) in the task manager. There is only one hash table, which is shared between the Rybka processes.

In other words, you can allocate roughly half of your RAM for the hash table without overflowing your available RAM, despite the task manager's indications to the contrary.

What is the purpose of the "Max CPUs" engine option?
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.

Does the "Max CPUs" value need to be set to a power of 2?
No. Any integral value of at least 1 is fine.

Is there any limit to how many processors Rybka 2.0 Beta can use?
In theory, no. We have tested on up to 8 processors. If you have a bigger machine, I'd be very interested to run my benchmark.

Are there any special interactions between the 32 bit vs 64 bit compiles and the multi-processor support?
No. The 64 bit version continues to run about 60% faster than the 32 bit version, regardless of how many processes are being used.



Rybka 2.1
July 26, 2006

FAQ

What is improved since Rybka 1.2?
1) Support for multiple processors
2) Various new endgame heuristics, helping Rybka understand that certain types of endgame advantages have little or no value
3) Improved search efficiency (ie. less time spent on unpromising continuations, leading to more attention to critical lines)
4) Some additional engine parameters controlling the interaction between the engine, user interface, and operating system
5) Long list of minor bug fixes and tweaks

Which improvements are planned for Rybka 2.2?
1) Adding chess knowledge
2) Improving search efficiency and multi-processing effeciency
3) Implementing tactical search modes, which put a higher emphasis on forcing tactical variations and give users faster feedback about the coarse-grained evaluation of a position (ie. is it clearly winning or clearly losing)

Can you explain the parameters of Rybka 2.1 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.


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.

8) Output: controls how much information the engine reports to the interface. Verbose reports large amounts of information, Sparse limits the output to minimal amounts.
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) 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.)
11) 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.)
12) 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.
13) 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.
14) 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.




Rybka 2.2
November 10, 2006

Differences between Rybka 2.2 and Rybka 2.1:

The author of the program Vasik Rajlich has managed to increase his program even more significantly and now its leadership among chess playing programs is beyond question.

It is confirmed not only by the rating of independent agency CEGT , but also by the significant victory at Dutch Open Computer Chess Championship 2006 with the result 9 out of 9!

If compared to version 2.1 new version 2.2 has the following advantages:

1) Rybka 2.2 is much better tactically.

2) Rybka 2.2 is much better in longer games.

3) Rybka 2.2 is better in blitz too. While testing the version one organized a blitz match (3' + 1" inc) between Rybka 2.2 and Rybka 2.1o ended with: +111 =206 -55 (+51 Elo).



Rybka 2.2n2
December 14, 2006

FAQ

What is the reason for this update?
The main reason for this version is the bug which can cause really strange output or a program crash of the multi-processor version - this is fixed now. The code is a lot more solid in general, the various problems there should be behind us now.

What about multi-processor performance?
I've spent a lot of time since the 2.2 release cleaning up and re-organizing this code and trying to understand everything. Measuring multi-processor performance is not a completely straightforward task. My conclusion at the moment is that there is nothing wrong with the performance and multi-processing efficiency of the 2.2 multi-processor version. The performance of the updated version is going to be negligibly (ie ~5 Elo) better.
This updated version of Rybka will display node counts which represent the multi-processing efficiency. (They are adjusted to take into account the wasted work.) So, you'll be able to compare the strength of different hardware, ie. you can compare a 4-core machine with a 2-core machine. The one with the better nodes-per-second is better

What else has been changed?
There are a bunch of other minor cosmetic changes, and new parameters:

a) "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.

b) "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.

c) "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.

d) "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.

Where's the contempt parameter in 2.2n2?
Sorry, during my re-organization I accidentally compiled it out. It will be back in Rybka 2.3.
If you really need it, I suggest you use 2.2 instead of 2.2n2.

Why does my Rybka not access tablebases? There is no access to the hard drive and in the engine output the tb=nnn item does not show up.
You need to set the parameter "Nalimov Usage" to "Normally" to enable TB access.
Note that "tbhits" won't be reported, this is a bug in 2.2n2 (will be fixed in 2.3).