Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / mp tablebases bug workaround updated
1 2 3 Previous Next  
- - By Lukas Cimiotti (Bronze) [de] Date 2009-07-21 15:36 Edited 2009-07-26 17:18
After Shahar, Majd and Roland gave me some great input ( thanks for that :) ), I played around with several configurations.
I can confirm that the bug will not be active if not all cores are used - it doesn't matter if the number is even or odd. It only matters that at least one core should be idle. So on a Nehalem EP with 16 logical cores everything is fine if you allow at max 15 cores. 14 are good, ... 8 are good. So switching Hyperthreading on, using half the number of logical cores and setting affinity to physical cores is a workaround that works for all computers that have Hyperthreading. But it's kind of a mess as for an 8 cores comp you need roughly 160 mouseclicks.

In Fritz GUI I found a much easier way that should also work with any mp computer. I can't try it with a Core 2 quad or Harpertown, as I don't have any of these in use anymore. So I'd ask anyone who is interested to try it and comment here.

In Fritz GUI:
Start Rybka by clicking "Change main engine". Click Engine parameters. Set MaxCPUs to 3 cores for a quad or 7 cores for an 8 cores comp. Load engine that way. Again click "Change main engine". Click Engine parameters. Set MaxCPUs to the number of cores you've got or any higher number. The bug is gone and all cores work :)

Please test it using this position:
8/4b3/5k2/5p2/3n4/6P1/2B3K1/5R2 w - - 0 52


Update

- it only works in the latest Fritz GUI

- there is a much easier way to do the workaround
Start Rybka with a hash size you don't want to use. Restart Rybka with a different hash size. That's it - no need to change number of cores :)

The problem is solved by a command that restarts Rybka's children tasks. Both setting number of cores and changing hash size do this.

You don't need this if you are using Aquarium or Shredder GUI.
Parent - - By bnc (***) Date 2009-07-21 17:04 Edited 2009-07-21 17:12
Nice find ! The workaround did the trick when using the CB gui option Tools/Analysis/Process Test Set ..

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=173483;hl=

This also explains for me at least why the problem seemed to be so sporadic ...once you proved a particular position was "infected" by changing the cpus to something less than maximum, if you returned to max cpus, then the infection also disappeared for positions that were previously infected ! It all makes sense now :)

Unfortunately, I dont see any way to use this workaround for CB GUI engine tournaments or matches as there doesnt appear to be any way to modify the engine once the match has started :(  

Also ..major credit to Peter Grayson , his recent post really shed a lot of light on this :

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=11832
Parent - By Roland Rösler (****) [de] Date 2009-07-21 21:39

>Also ..major credit to Peter Grayson


Indeed, Peter made the right question and decisive suggestion!
Parent - By Lukas Cimiotti (Bronze) [de] Date 2009-07-22 17:20
Yes, you are right - looks like Peter first found it. Thanks for that. :)
Parent - - By ernest (****) [fr] Date 2009-07-21 17:29 Edited 2009-07-21 17:33
The workaround also works on my Core 2 Duo, with all 3-4-5 Nalimovs, Fritz 11 GUI.
8/4b3/5k2/5p2/3n4/6P1/2B3K1/5R2 w - - 0 1
Analysis by Rybka 3 32-bit:
2 cores: (EGTB bug)
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bf6 4.Rf3 Bd8 5.Kf2 Kf6 6.Rf4 Bc7 7.Ke3 Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Ke8 12.Kg4 Kf8 13.Kf5 Kf7
  +-  (2.82)   Depth: 26   00:04:08  20520kN, tb=16616
1.Bxf5 Nxf5[] 2.g4[] Kg5[] 3.gxf5[] Bf6 4.Rf3 Bd8 5.Kf2 Kf6 6.Rf4 Bc7 7.Ke3 Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Ke8 12.Kg4 Kf8 13.Kf5 Kf7
  +-  (2.82)   Depth: 27   00:05:53  28941kN, tb=27238
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bf6 4.Rf3 Bd8 5.Kf2 Kf6 6.Rf4 Bc7 7.Ke3 Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Ke8 12.Kg4 Kf8 13.Kg5 Kf7 14.Kf5
  +-  (2.82)   Depth: 28   00:08:22  41359kN, tb=41851
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bf6 4.Rf3 Bd8 5.Kf2 Kf6 6.Rf4 Bc7 7.Ke3 Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Ke8 12.Kg4 Kf8 13.Kg5 Kf7 14.Kf5[]
  +-  (2.82)   Depth: 29   00:12:16  60735kN, tb=64590
1 core: (no bug)
1.Bd3 Ke5 2.Re1+ Kd6 3.Bc4 Bg5 4.Re8 Be7 5.Ra8 Ke5 6.Ra5+ Kf6 7.Rd5
  +-  (1.66)   Depth: 24   00:02:56  10054kN, tb=10738
1.Bd3 Ke5 2.Re1+ Kf6 3.Ra1 Bc5 4.Ra5 Bd6 5.Bc4 Nc2 6.Kf2 Nd4
  +-  (1.66)   Depth: 25   00:05:14  18110kN, tb=18451
1.Bd3 Ke5 2.Re1+ Kf6 3.Ra1 Bc5 4.Ra5 Bd6 5.Bc4 Nc2 6.Kf2 Nd4
  +-  (1.66)   Depth: 26   00:07:02  24137kN, tb=28139
1.Bd3 Ke5 2.Re1+ Kf6 3.Ra1 Bc5 4.Ra5 Bd6 5.Bc4 Nc2 6.Kf2 Nd4
  +-  (1.66)   Depth: 27   00:10:19  35488kN, tb=44710
2 cores (after workaround MaxCPUs set to 1, then back to 2048): no bug
1.Bd3 Kg5 2.Ra1 Bc5 3.Ra5 Bb6 4.Rd5 Ba7 5.Rd8 Kf6 6.Bc4 Kg5 7.Kh3 Kf6 8.Kh4 Nf3+ 9.Kh5[] Bc5 10.Re8 Be7 11.Ra8 Bd6 12.Ra6 Ke5 13.Ra5+ Kf6
  +-  (1.64)   Depth: 26   00:04:06  22849kN, tb=18092
1.Bd3 Kg5 2.Ra1 Bc5 3.Ra5 Bb6 4.Rd5 Ba7 5.Rd8 Kf6 6.Bc4 Kg5 7.Rg8+ Kf6 8.Ra8 Bc5 9.Ra5
  +-  (1.64)   Depth: 27   00:05:57  33370kN, tb=27713
1.Bd3 Kg5 2.Ra1 Bc5 3.Ra5 Bb6 4.Rd5 Ba7[] 5.Rd8 Kf6 6.Bc4 Kg5 7.Rg8+ Kf6 8.Ra8 Bc5 9.Ra5
  +-  (1.64)   Depth: 28   00:09:36  54836kN, tb=44793
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rd5 Be5
  +-  (1.64)   Depth: 29   00:18:35  111mN, tb=86364
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rd5 Be5 6.Rd8 Kg5 7.Rg8+ Kf6 8.Kf2 Bd6 9.Rc8
  +-  (1.64)   Depth: 30   00:27:30  164mN, tb=131162
Parent - By Lukas Cimiotti (Bronze) [de] Date 2009-07-21 17:40
Thanks for testing :)
Parent - - By M ANSARI (*****) [kw] Date 2009-07-21 17:46
I will test it today on my Octa.  If this works then this is as good as Rybka 3+ , for me anyway.
Parent - By M ANSARI (*****) [kw] Date 2009-07-21 17:53 Edited 2009-07-21 17:58
OK I can confirm that the fix works for Rybka 3 on Octa.  Changed to 7 cpu's and load then change to 8 cpu.  I checked all 8 cpu's are 100% loaded and this is output.  Good job Lukas!  Great thing is that no need to load only 7 cores and can have Rybka at full power.  For the life of me I have no clue why that works!  Anyway Rybka will be unleashed now ;) 

New game
8/4b3/5k2/5p2/3n4/6P1/2B3K1/5R2 w - - 0 1


Analysis by Rybka 3_FIXED:

1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4
  +-  (1.63)   Depth: 18   00:00:00  0kN
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4
  +-  (1.63)   Depth: 19   00:00:00  0kN
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rc5 Bd6 6.Rd5
  +-  (1.63)   Depth: 20   00:00:00  130kN, tb=27
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rc5 Bd6 6.Rd5
  +-  (1.63)   Depth: 21   00:00:01  515kN, tb=141
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rd5 Be5 6.Rd8
  +-  (1.64)   Depth: 22   00:00:04  1600kN, tb=521
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rd5 Be5 6.Rd8 Ke7 7.Ra8 Kf6 8.Kf2
  +-  (1.64)   Depth: 23   00:00:06  2484kN, tb=819
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rd5 Be5 6.Rd8 Kg5 7.Kf2 Bc7 8.Rg8+
  +-  (1.64)   Depth: 24   00:00:09  3886kN, tb=1182
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bc7 5.Rd5 Be5 6.Rd8 Kg5 7.Kf2 Bc7 8.Rg8+
  +-  (1.64)   Depth: 25   00:00:17  6771kN, tb=2336
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Be5 5.Kf2 Bd6 6.Ra6 Ke5 7.Ke3 Nc2+ 8.Ke2 Nb4 9.Rb6 Nc2 10.Ba2 Nd4+ 11.Kd3 Nf3 12.Rb5+ Kf6 13.Ke3 Nh2 14.Rb6
  +-  (1.64)   Depth: 26   00:00:30  12438kN, tb=3587
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bb8 5.Kf2 Bd6 6.Ra6 Ke5 7.Ke3 Nc2+ 8.Ke2 Nb4 9.Rb6 Nc2 10.Ba2 Nd4+ 11.Ke3 Bc5 12.Ra6 Ne6+
  +-  (1.64)   Depth: 27   00:00:49  20998kN, tb=5724
1.Bd3 Kg5 2.Ra1 Bd6 3.Ra5 Kf6 4.Bc4 Bb8 5.Kf2 Kg5 6.Ra8 Bd6 7.Rg8+ Kf6 8.Rd8 Bc5 9.Rc8
  +-  (1.64)   Depth: 28   00:01:20  34131kN, tb=9460

(,  21.07.2009)

New game
8/4b3/5k2/5p2/3n4/6P1/2B3K1/5R2 w - - 0 1


Analysis by Rybka 3 (Default with EGTB bug):

1.Bxf5
  +-  (2.15 !)   Depth: 6   00:00:00  0kN
1.Bxf5 Nxf5 2.g4 Kg5 3.gxf5 Kf6 4.Kh3
  +-  (2.29)   Depth: 6   00:00:00  1kN
1.Bxf5 Nxf5 2.g4 Kg5 3.gxf5 Bf6 4.Rf3 Bd4 5.Kg3 Bf6 6.Kf2
  +-  (2.30)   Depth: 7   00:00:00  2kN
1.Bxf5 Nxf5 2.g4 Kg5 3.gxf5 Bf6 4.Rf3 Bd4 5.Kg3
  +-  (2.30)   Depth: 8   00:00:00  2kN
1.Bxf5 Nxf5[] 2.g4 Kg5 3.gxf5 Bf6 4.Rf3 Be7 5.Kf2 Kf6 6.Ke2 Bd8
  +-  (2.49)   Depth: 9   00:00:00  7kN
1.Bxf5 Nxf5[] 2.g4 Kg5 3.gxf5 Bf6 4.Rf3 Be7 5.Kf2 Kf6 6.Ke2 Bd8
  +-  (2.49)   Depth: 10   00:00:00  7kN
1.Bxf5 Nxf5[] 2.g4 Kg5 3.gxf5 Bf6 4.Rf3 Be7 5.Kf2 Kf6 6.Ke2 Bd8
  +-  (2.46)   Depth: 11   00:00:00  7kN
1.Bxf5 Nxf5[] 2.g4 Kg5 3.gxf5 Bd8 4.Rf3 Be7 5.Kf2
  +-  (2.46)   Depth: 12   00:00:00  8kN
1.Bd3 Kg5 2.Re1 Bd6 3.Re8 Kf6 4.Rd8 Ke7 5.Rh8 Ke6
  +-  (1.57)   Depth: 13   00:00:00  424kN, tb=9
1.Bd3 Kg5 2.Re1 Bd6 3.Re8 Kf6 4.Rd8 Ke7 5.Ra8 Kf6 6.Ra6
  +-  (1.59)   Depth: 14   00:00:01  522kN, tb=16
1.Bxf5 Ke5 2.Bd3 Bd8 3.Rh1
  +-  (2.76 !)   Depth: 14   00:00:01  522kN, tb=16
1.Bxf5 Ke5 2.Bd3 Bd8 3.Rh1
  +-  (2.76)   Depth: 14   00:00:01  522kN, tb=16
1.Bxf5 Ke5 2.Bd3 Bd8 3.Rh1
  +-  (2.76)   Depth: 15   00:00:01  522kN, tb=16
1.Bxf5 Ke5 2.Bd3 Bd8 3.Rh1
  +-  (2.78)   Depth: 16   00:00:01  527kN, tb=16
1.Bxf5 Ke5 2.Bd3 Nc6 3.g4 Nd4 4.Re1+ Kd6[] 5.Ra1 Bg5
  +-  (2.78)   Depth: 17   00:00:01  800kN, tb=40
1.Bxf5 Ke5 2.Bd3 Bd8
  +-  (2.79)   Depth: 18   00:00:03  1707kN, tb=103
1.Bxf5 Ke5 2.Bd3 Bd8 3.Rh1 Bg5 4.Kh3 Be7 5.Kg4 Bd6 6.Rh5+ Ke6 7.Bc4+ Kf6[] 8.Bb5
  +-  (2.79)   Depth: 19   00:00:04  2509kN, tb=165
1.Bxf5 Ke5 2.Bd3 Kd5 3.Re1 Bg5 4.Re8 Bf6 5.Be4+ Kd6 6.g4 Bg5 7.Kg3 Bf6 8.Ra8 Ke5 9.Bd3
  +-  (2.90)   Depth: 20   00:00:08  4648kN, tb=389
1.Bxf5 Nxf5[]
  +-  (2.90)   Depth: 21   00:00:11  6035kN, tb=653
1.Bxf5 Nxf5[] 2.g4 Kg5 3.gxf5[] Bd8 4.Rf3 Be7 5.Kf2 Kf6 6.Rf4 Bd6 7.Ke3[] Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Kf7 12.Kf5
  +-  (2.90)   Depth: 22   00:00:12  6445kN, tb=860
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bd8 4.Rf3[] Be7 5.Kf2 Kf6 6.Rf4 Bd6 7.Ke3[] Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Kf7 12.Kf5
  +-  (2.90)   Depth: 23   00:00:15  8043kN, tb=1346
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bd8 4.Rf3 Be7 5.Kf2 Kf6 6.Rf4 Bd6 7.Ke3[] Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf4 Kf7 12.Kf5
  +-  (2.90)   Depth: 24   00:00:22  10171kN, tb=2172
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bd8 4.Rf3 Be7 5.Kf2 Kf6 6.Rf4 Bd6 7.Ke3[] Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.f6 Kf8[] 11.Kf5 Kf7 12.Kg5[] Kf8
  +-  (2.90)   Depth: 25   00:00:28  12416kN, tb=3419
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bd8 4.Rf3 Be7 5.Kf2 Kf6 6.Rf4 Bd6 7.Ke3[] Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.Kd5 Ke7 11.Kd4 Kf6 12.Ke4 Kf7
  +-  (2.90)   Depth: 26   00:00:40  16257kN, tb=5149
1.Bxf5 Nxf5[] 2.g4[] Kg5 3.gxf5[] Bd8 4.Rf3 Be7 5.Kf2 Kf6 6.Rf4 Bd6 7.Ke3[] Bxf4+ 8.Kxf4 Ke7 9.Ke5 Kf7[] 10.Kd5 Ke7 11.Kd4[] Kf6 12.Ke4
  +-  (2.90)   Depth: 27   00:00:58  22302kN, tb=7440

(,  21.07.2009)
Parent - - By Dragon Mist (****) [hr] Date 2009-07-21 17:48
We need to erect a monument for this finding! I use R3 for infinite on quad. So, all I have to do is to enter R3 parameters (from any position, like starting?), change MaxCPU to 3, OK, (nothing is required in between, like letting engine think for a while or so?), then enter parameter dialogue again, change MaxCPU to 4, and OK??

If so, can you help me with this: for unknown reasons to me, when R3 is run with all 4 cores as default, my PC gets very irresponsive, and my workaround was to go to Task Manager (after loaded R3 in F11 GUI), find a single R3 process that has Normal priority (one is always on Normal, the other 3 are on Below Normal), and change it to Below Normal). After that everything works ok, and irresponsiveness is reduced to like 1-2% of what was before. How will this procedure affect the above described MB TB bug workaround?
Parent - - By Lukas Cimiotti (Bronze) [de] Date 2009-07-21 18:28
You don't have to make the engine think - just change parameters.

>How will this procedure affect the above described MB TB bug workaround?


Maybe you could test it yourself - I'm quite confident it has no effect at all on the bug.
Parent - By Dragon Mist (****) [hr] Date 2009-07-21 18:53
Thanks Kullberg, of course, I'll test it, I just let go my questions off sometimes without thinking properly about them. :-)
Parent - - By keoki010 (Silver) [us] Date 2009-07-21 18:04
It works on my i7-920 hyperthreading on with R3 set to 4 cores.  Didn't need to do anything else.  GUI=Aquarium
I've got an intel core-2 I'll try it on.
Parent - - By Dadi Jonsson (Silver) [is] Date 2009-07-21 18:09
Did you also test in Aquarium with hyperthreading off?
Parent - - By keoki010 (Silver) [us] Date 2009-07-21 18:15
no, I just test hyperthreading on.
Parent - - By Dadi Jonsson (Silver) [is] Date 2009-07-21 18:21
You should test again (in Aquarium) with hyperthreading off :wink:
Parent - - By keoki010 (Silver) [us] Date 2009-07-21 18:47
How do I turn it off?  BIOs? Running Vista Ultimate x64
Parent - By Dadi Jonsson (Silver) [is] Date 2009-07-21 20:19
It's probably a BIOS setting, so have a look at the motherboard manual (or wait for an answer from someone else who knows).
Parent - - By Lukas Cimiotti (Bronze) [de] Date 2009-07-21 20:57
It is a BIOS setting.
Don't mess around with the BIOS if you don't know what you are doing.
Parent - By keoki010 (Silver) [us] Date 2009-07-21 21:36
Ok, thanks.  That's why I left it on.  Haven't had any troubles.  :smile:
Parent - By Linus (***) [at] Date 2009-07-21 18:41
I tested it with Aquarium (or tried to) on my 8 core Harpertown. The bug is not there. Rybka comes up with the right move without messing around with engine parameters. Has anybody confirmed that the EGTB bug exists in Aquarium? Are there any other test positions?

I can reproduce the above procedure with the CB GUI. The fix works there.
Parent - - By Lukas Cimiotti (Bronze) [de] Date 2009-07-21 18:24
That's not the way to do it - you'll waste 20% CPU power
Parent - By keoki010 (Silver) [us] Date 2009-07-21 18:50
Sure but I only play corr. and against my own computer.  I don't worry about beating R3, I have troubles enough just getting a draw at 1200.
Parent - - By Dadi Jonsson (Silver) [is] Date 2009-07-21 18:45
Another workaround is simply using Aquarium :cool:

This is what I get in Aquarium without any kind of mouse gymnastics, running on all 8 cores (3-4-5 and some 6 piece EGTB). It also gets the Peter Grayson position correctly.

[+1.64]  d=31  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 Bc3 56.Rc4 Bb2 57.Bb1 Kg5 58.Rc5 Ba3 59.Rd5 Bb2 60.Rd6 (0:08.58) 60332kN
[+1.64]  d=30  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 Bc3 56.Rc4 Bb2 57.Bb1 Kg5 58.Rc5 Ba3 59.Rd5 Bb2 60.Rd6 (0:06.08) 28266kN
[+1.64]  d=29  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 (0:04.34) 13733kN
[+1.64]  d=28  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 Bc3 56.Rc4 Bb2 57.Bb1 Kg5 58.Rc5 Ba3 59.Rd5 Bb2 60.Rd6 (0:03.57) 10817kN
[+1.64]  d=27  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 (0:02.37) 5644kN
[+1.64]  d=26  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 (0:01.57) 3586kN
[+1.64]  d=25  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 (0:01.24) 2545kN
[+1.64]  d=24  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 Bc3 56.Rc4 Bb2 57.Bb1 Kg5 58.Rc8 Ba3 59.Kf2 (0:01.03) 2185kN
[+1.64]  d=23  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 Bc3 56.Rc4 Bb2 57.Bb1 Kg5 58.Rc8 Ba3 59.Kf2 (0:00.48) 1892kN
[+1.63]  d=22  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Bb4 55.Ra4 Bc3 56.Rc4 Bb2 57.Rc8 Ba3 58.Rd8 (0:00.29) 1436kN
[+1.63]  d=21  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Kg5 55.Ra5 Kg4 56.Ra7 Bf6 57.Rf7 Kg5 58.Rf8 Be5 59.Ra8 (0:00.18) 1007kN
[+1.63]  d=20  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Kg5 55.Ra5 Kg4 56.Ra7 Bf6 57.Rf7 Kg5 58.Rf8 Be5 59.Ra8 (0:00.12) 897kN
[+1.63]  d=19  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Kg5 55.Ra5 Kg4 56.Ra7 Bf6 57.Rf7 Kg5 58.Rf8 Be5 59.Ra8 (0:00.09) 831kN
[+1.63]  d=18  52.Bd3 Ke5 53.Re1+ Kf6 54.Ra1 Kg5 55.Ra5 Kg4 56.Ra7 Bf6 57.Rf7 Kg5 58.Rf8 Be5 59.Ra8 (0:00.07) 805kN
[+1.62]  d=17  52.Bd3 Ke5 53.Re1+ Kf6 54.Bc4 Bf8 55.Kf2 Bc5 56.Re8 Ne6+ 57.Kg2 Ng5 58.Bd5 Bd6 (0:00.05) 680kN
[+1.62]  d=16  52.Bd3 Ke5 53.Re1+ Kf6 54.Bc4 Bb4 55.Re3 Kg5 56.Kf2 Bc5 57.Re5 Bb6 58.Kg2 Nc2 (0:00.04) 603kN
[+1.63]  d=15  52.Bd3 Ke5 53.Re1+ Kf6 54.Bc4 Bb4 55.Re3 Kg5 56.Kf2 Bc5 57.Re5 Bb6 (0:00.03) 483kN
[+1.62]  d=14  52.Bd3 Ke5 53.Re1+ Kf6 54.Bc4 Bb4 55.Re8 Bd2 56.Rg8 Be3 (0:00.02) 325kN
[+1.61]  d=13  52.Bd3 Kg5 53.Re1 Bd6 54.Re8 Bc7 55.Kf2 Bb6 56.Bc4 Nc6+ 57.Ke2 (0:00.01) 125kN
[+1.55]  d=12  52.Bd3 Kg5 53.Re1 Bf6 54.Re8 Kg4 55.Kf2 Bg5 56.Bf1 (0:00.00) 73kN
Parent - By Lukas Cimiotti (Bronze) [de] Date 2009-07-21 18:47
Cool - I already wanted to ask you to find something similar for Aquarium ;)
Parent - - By Ray (****) Date 2009-07-21 19:01

> Another workaround is simply using Aquarium :cool:


Hmm.. must give Aquarium another go. I've hardly used it in the months I've had it, couldn't get my head round it.
Parent - By Dadi Jonsson (Silver) [is] Date 2009-07-21 20:20
Remember to update to the latest version first.
Parent - By keoki010 (Silver) [us] Date 2009-07-21 19:10 Edited 2009-07-21 19:16
Ok, I tried in Chess Assistant 10. i7-920 2.67Ghz hyperthreading on.  R3 default set to 4 cpu's The bug is there.  stopped analyizing set the analysis to multipv=2 bug wasn't there.  CPU set to 4 not 2048.
Parent - By Vasik Rajlich (Silver) [pl] Date 2009-07-22 05:30
Aquarium must be sending a "setoption name max cpus value x" command automatically. Maybe it's helping the user handle hyperthreading?

Vas
Parent - - By Roland Rösler (****) [de] Date 2009-07-22 21:15

>Another workaround is simply using Aquarium


Another workaround is simply using Shredder 11 GUI! :-)

I have tested it with the GUI of our UCI pope (SMK) and can´t find any EGTB bug in Rybka 3.
So the whole trouble with Rybka EGTB bug is only a GUI issue and CB is guilty as usual? I like this idea (fact)!

My conclusion: Vas has to look for his partners more carefully!

PS: It will be interesting to see, when new F11 update will come.
Parent - - By ernest (****) [fr] Date 2009-07-22 21:22

> Another workaround is simply using Shredder 11 GUI!


... and forget about Sampled Search!
Parent - - By keoki010 (Silver) [us] Date 2009-07-23 13:34
No, I like sampled search.
Parent - - By ernest (****) [fr] Date 2009-07-23 16:08
You get Sampled Search only with Fritz/ChessBase and Aquarium GUIs...  :-)
Parent - By keoki010 (Silver) [us] Date 2009-07-23 16:13
I use it in Aquarium.
Parent - - By Highendman (****) Date 2009-07-23 16:18
What's 'sampled search'? I guess it's time I buy this Aquarium thing too.
Parent - By keoki010 (Silver) [us] Date 2009-07-23 16:25
It shows you some behind the scenes searchs when its building the pv.
Parent - By Dadi Jonsson (Silver) [is] Date 2009-07-23 16:31
Here is some info about sampled search from the Aquarium FAQ (near the end of the page): http://rybkaforum.net/tutorials/FAQ/infinite_analysis.html
Parent - By Lukas Cimiotti (Bronze) [de] Date 2009-07-23 16:34
This is sampled search:
Parent - - By Wayne Lowrance (***) Date 2009-07-21 20:24
Wow, good job, work on MacPro :)
Wayne
Parent - - By Wayne Lowrance (***) Date 2009-07-21 21:03
Question. During IA analysis proceeding forward and reverse in the PV
lines, do you have to redu the eng paramater thing over and over again,
for each new position or just the once at the beginning of the IA set up ?
Thanks
Wayne
Parent - By Wayne Lowrance (***) Date 2009-07-21 21:16
Sorry, just answered my own question after further
checking
Wayne
Parent - - By Roland Rösler (****) [de] Date 2009-07-21 21:32
What do you think Lukas:

1. Will there be the EGTB bug on a single core machine (no HT!) using Rybka 3 for multi processor (core) with Fritz GUI?
2. Will there be the EGTB bug on a single core machine (no HT!) using Rybka 3 for single processor (core) with Fritz GUI?

I´m a little bit uncertain, but I think yes. To test it, you need a single core machine (which I don´t have). We all thought the EGTB bug is a mp issue, because we couldn´t see the bug on single core (on our multi core machines).
Poor Vas! :-) Maybe he was looking for differences between mp and sp version to find the bug. But now I think the bug is in sp version too!

Last remark: Do you have a workaround for single core machines too? :-)
Parent - By Vasik Rajlich (Silver) [pl] Date 2009-07-22 05:31
1) No
2) No

Vas
Parent - - By Omega-three (**) Date 2009-07-21 22:53
Hi Kullberg

On my quad I only have 4 man tbs and I cannot get this work around to work, no matter how many processors I set it to Rybka still shows Bxf5 ? does this only work with at least 5 man tbs ?

Regards

Mike
Parent - By Vempele (Silver) [fi] Date 2009-07-21 22:58
Probably because Rybka needs 5-man TBs in this particular position...
Parent - - By Highendman (****) Date 2009-07-22 04:05
Brilliant find Lukas. Very impressive. For the life of me I can't theorize how loading the engine with 7/8 or 3/4 processes and then immediately loading it again with 8/8 or 4/4 cores makes the bug go away. But it works which is super cool. If you can now find some magic that would make the bug go away in engine vs. engine playchess games and not just in offline analysis mode - then Rybka 3.5 is out ;)
Parent - By Lukas Cimiotti (Bronze) [de] Date 2009-07-22 07:03

>If you can now find some magic that would make the bug go away in engine vs. engine playchess games and not just in offline analysis mode - then Rybka >3.5 is out 


I guess it should work the same way - but I'll test it ;)
Parent - - By M ANSARI (*****) [kw] Date 2009-07-22 07:23 Edited 2009-07-22 07:37
I don't understand why it wouldn't work for Playchess games, apparently the work around sets some parameters in Rybka that are permanent.  Thus unloading and loading engines should not be affected.  Ofcourse this has to be tested for playing engine tournaments at home, but for Playchess it shouldn't be a problem and at worse you would simply have to do the work around before starting you Playchess games every time you load your engine.

Anyway I am quite sure that this thing will be solved in Rybka 4 as Vas has plenty of data now to fix the problem.  This seems to be less of a Rybka engine bug and more like a bug related to interaction of the engine and Nalimov code.  Somehow it seems that the engine is taking all resources including resources needed to get the nalimov code working properly.  Somehow changing the engine parameters in number of CPU's fixes the thing.  I am beginning to think that it might be due to setting the CPU's too high by the default parameters which somehow assume there are more CPU's than there really are ... maybe caused by hyperthreading code.  I say that because when I put 7 cores to be used, I still have all 8 cores being used with 3 cores dropping in 100% usage.  I would have thought that the profile in task manager would be 7 cores would be at 100% and 1 core would be less than 100%.  Either that or 8 cores would be at approximately 7/8 of 100%.  Also remember that Rybka uses processes and not threads.
Parent - - By bnc (***) Date 2009-07-22 07:41

>the work around sets some parameters in Rybka that are permanent


Permanent ? I do not see where that is true.

Engine matches and tournaments in the CB GUI still have the MP EGTB problem. It seems that everytime a Rybka engine is loaded, you must apply the workaround. I have tried but once an engine match or tournament is started,  there doesnt appear to be any way to apply the workaround ??
Parent - By M ANSARI (*****) [kw] Date 2009-07-22 07:57
It would be great if you could test it although I am not sure how you can tell if it is working or not on Playchess.  I guess you have wait for an endgame in one of your games that gets the bug hit.  I estimate that the bug should hit 10% to 20% of the games so you would have to play quite a few games and check it out.  Try making a new Rybka engine by doing the work around and give it a name such as Rybka_FIX and play about 20 games on Playchess.  Hopefully that will be enough games to get a bug hit.  If the bug is still there then that would mean that a fix .dll file or script would be needed in the same engine folder to ensure this is done everytime the engine is loaded.  I remember Naum had such a file which you have to configure to tell the engnie how many cores should be used, and also the earlier versions of Zappa.
Parent - - By ernest (****) [fr] Date 2009-07-22 09:13

> Engine matches and tournaments in the CB GUI still have the MP EGTB problem. It seems that everytime a Rybka engine is loaded,...


Why would engine matches have the problem? Until the end of the match, Rybka is never reloaded.
Up Topic Rybka Support & Discussion / Rybka Discussion / mp tablebases bug workaround updated
1 2 3 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill