Ubuntu: latest wine update breaks rybka

[govert]

It seems that the lates wine updates for Ubuntu 8.04 and 8.10 breaks rybka somehow.
The symptom is a very low cpu usage and nps count.

Using the binary from wine 1.0 seems to fix this.
(I extracted the wine binary from the 1.0 deb package)


Can anyone else confirm this?

EDIT: this post concerns rybka 2.2n2 32 bit

[royb]

It seems that the lates wine updates for Ubuntu 8.04 and 8.10 breaks rybka somehow.
The symptom is a very low cpu usage and nps count.

Using the binary from wine 1.0 seems to fix this.
(I extracted the wine binary from the 1.0 deb package)


Can anyone else confirm this?

EDIT: this post concerns rybka 2.2n2 32 bit

I am running Ubuntu 8.10 64-bit with wine 1.0.1 installed and Rybka 2.2n2 32bit works for me on those rare occasions when I run it.

I don't run Rybka3 64-bit anymore though as there is an issue when running under SCID that I've given up on figuring out. I don't think it is Rybka3 but I've just stopped trying; the engine just crashes on launch. That's another reason to like native Linux chess engines like Naum4, Glaurung 2.2, Crafty 22.10 ... there is a long list of free engines and Naum4 of course is the second strongest commercial engine and now supports Linux.

Roy

[Kurt Utzinger]

It seems that the lates wine updates for Ubuntu 8.04 and 8.10 breaks rybka somehow.
The symptom is a very low cpu usage and nps count.

Using the binary from wine 1.0 seems to fix this.
(I extracted the wine binary from the 1.0 deb package)

Can anyone else confirm this?

EDIT: this post concerns rybka 2.2n2 32 bit

I am using Linux Ubuntu 8.04.2 with wine 1.0 and Rybka is running fine
as long a I do not set up hash tables over 32 MB.

Kurt

[krazyken]

There is a "microwine" you can find somewhere on the rybka site that should work well for running Rybka.

[royb]

There is a "microwine" you can find somewhere on the rybka site that should work well for running Rybka.

Microwine is for using 64-bit Rybka engines under Linux. It used to work for me but no longer does for my 64-bit Rybka-3. I've given up on it and just use other engines; I refuse to live with software that works one day and not the next even though I know it's not a Rybka-3 problem, that doesn't make it any easier on the customer (me).

I won't be buying any further Rybka products until they release a native Linux port (which may be never but hey).

[govert]

Kurt, what happens when you set hash > 32 ?

[Kurt Utzinger]

Kurt, what happens when you set hash > 32 ?

Well, in that case Rybka is doing very, very slow and permanently has
access to the hard disk. My PC (Intel Quad Q6600) has only 2 GB ram and
for Rybka/Loop MP 12.32 the hash table size must be set to 16 MB or 32 MB
only. In case of setting 16 MB hash, Rybka uses a total of 290 MB ram
(3 x 72,0 MB + 1 x 74,7 MB). It is however intersting that Naum 4 (4cpu)
takes only a total of 64 MB ram if hash tables are set to 16 MB. It seems to
be necessary to check with each individual chess program with the system
monitor how many rams are actually used.
Kurt

[glorfindel]

I have had a problem in the past, (first with Crafty, then with Rybka) maybe it is relevant and maybe not. It could be irrelevant because the engines would not start at all.

Anyway, the problem was that, when creating their hashtables, Crafty and Rybka need the memory allocated to them to be in one big chunk, but the linux kernel has an option which puts a limit to the maximum size of that memory. In my system the default was 32MB, which is quite low, and Crafty would not start.

The kernel option is called kernel.shmmax. There is a configuration file where you can set it, on my system it is /etc/sysctl.conf. I added one line

Code: Select all

kernel.shmmax = 0x20000000

to make it 2^29 Bytes = 512MB. This way it is set at every boot.

You can see the current value of this parameter (if you are superuser) with the command

Code: Select all

sysctl kernel.shmmax

and you can set it to a new value immediately with

Code: Select all

 sysctl -w kernel.shmmax=0x20000000

.

It is strange that most engines didn't have this problem, but Crafty and Rybka did.

[govert]

Christos, this certainly looks interesting.
I chn confirm that I am also having problems when setting hash > 32MB in rybka.
I will test and see what happens.

[bob]

I have had a problem in the past, (first with Crafty, then with Rybka) maybe it is relevant and maybe not. It could be irrelevant because the engines would not start at all.

Anyway, the problem was that, when creating their hashtables, Crafty and Rybka need the memory allocated to them to be in one big chunk, but the linux kernel has an option which puts a limit to the maximum size of that memory. In my system the default was 32MB, which is quite low, and Crafty would not start.

The kernel option is called kernel.shmmax. There is a configuration file where you can set it, on my system it is /etc/sysctl.conf. I added one line

Code: Select all

kernel.shmmax = 0x20000000

to make it 2^29 Bytes = 512MB. This way it is set at every boot.

You can see the current value of this parameter (if you are superuser) with the command

Code: Select all

sysctl kernel.shmmax

and you can set it to a new value immediately with

Code: Select all

 sysctl -w kernel.shmmax=0x20000000

.

It is strange that most engines didn't have this problem, but Crafty and Rybka did.

That is not a "max malloc()" issue. "shmmax" is a different kind of malloc, specifically it is about "shmget()" which allocates a permanent chunk of shared memory that will not go away unless either the program (some program) removes it, or the program that creates it tells the system to destroy it when the program exits. The reason there is such a limit is that a program could, if it wanted to, shmget() a huge chunk of memory and then exit, and that memory doesn't go away.

Normal malloc() has _nothing_ to do with the shmmax value (which can also be set by "echo nnn > /proc/sys/kernel/shmmax"). Apparently Rybka chose to use the same methodology I used for managing shared memory (there are lots of other ways, not many use shmget()/shmat()) which is certainly OK since anyone can look at the previous non-thread versions to see how I was doing things...

Crafty no longer uses this so for it, the issue has gone away...