Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Is the Zero KN/S Cosmetic?
1 2 Previous Next  
- - By billyraybar (***) Date 2007-06-16 10:46 Edited 2007-06-16 10:52
Buried in another post (http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=1258) I and others discussed the problem that kn/s is sometimes being displayed as zero or a very low number.  Just wondering if anyone can confirm that the issue is only cosmetic.  Once again it happens only at a specific time.  If you look at the file I attached, depth 19 popped up immediately (in zero seconds) and the kn/s is very low.  The kn/s will show a normal level when the first move is calculated which happens to be after 7 minutes and 12 seconds in the second image I attached. 
Parent - - By Vasik Rajlich (Silver) Date 2007-06-16 10:48
The PVs with 0 nodes are literally constructed without any searching at all. Everything is re-used from the transposition table.

Vas
Parent - - By billyraybar (***) Date 2007-06-16 10:54
Thanks
Parent - By Kapaun (****) Date 2007-06-16 13:22
That would mean it's "cosmetic", I guess. So my grease old mechanical intuition didn't betray me... ;-)
Parent - - By Jitugo (**) Date 2007-06-16 16:03
Its cosmetic if you have infinite time... but on playchess rybka 2.3.2 looses on time because of this - i think the rybka / gui communication is somehow stalled because after it restarts outputing it sends all iterations (depth 17-18-19) immediatly with no difference in the node count. if it happens and your not low on time, nothing much will happen, rybka will only take a little bit more of time than its time allocation algorithm probably would like. But in bullet or blitz with only 10 sec or less to go - rybka will loose on time. Saw it about 10 times with a couple of games having rybka up +5.xx winning.
Parent - - By Michael Waesch Date 2007-06-16 16:27
I am also not sure about the cosmetic factor. On 32 bit Rybka 2.3.2 often gets completely paralysed.

Mike
Parent - - By Kapaun (****) Date 2007-06-16 18:17
Not here. The CPU(s) are always fully working...
And, lets be honest: When Rybka is calculating the first move of a new, somewhat higher ply it always looks sort of "paralyzed". The only difference to earlier Rybka versions is that it didn't attract attention because some KN count and a move was displayed.
Parent - - By Michael Waesch Date 2007-06-16 20:02
Sorry, but when an engine is locked at ply 12 and I let it run for an additional 5 minutes, also noticing that the thread is still runing full force, but Rybka remains at ply 12, I just assume it´s locked.

I then re-checked the working status by going moves back and forth and Rybka refuses to analyse at all...

And after we have seen all the Zugzwang-positions here in there forum where Rybka is still not able to solve them, it has become quite clear that Vasik´s claim in the 2.3.2 readme is plain wrong.

Now I see the 2.2 easily holding ground on my local tournaments and slowly get doubts about the increase in playing strength also.

Mike
Parent - - By Kapaun (****) Date 2007-06-16 20:27 Edited 2007-06-16 20:30
Hm, I see. In this case we are probably talking about two different phenomenons which only seem to be similar at the first glance - but are not. No doubt here that 2.3.2 is quite a bit stronger than previous versions...
Maybe you should try to create the UCI engine a second time, as Vas is proposing, while deleting the TB path in your GUI. After creating the engine, you can activate the TB path again. At least that's what Vas is saying.
Parent - By Michael Waesch Date 2007-06-16 20:38
No need for that. It only happens to the 32-bit single version. For online playing or analysing my games I use the MP 64 bit which works fine. And the tournaments run with the single 64 bit which also does not have the problem, but although the 2.3.2 reaches slightly higher depths it is now 1 pt behind 2.2 and only 8 more games to be played.

I only checked the 32-bit single because I wanted to see if the complaints of people using it are justified and back them up if I could reproduce it.

Mike
Parent - By billyraybar (***) Date 2007-06-16 21:02
I wasn't aware Vas suggested this.  Anyhow, thanks.  I'll try it.
Parent - - By Felix Kling (Gold) Date 2007-06-16 21:36
This is only for the "engine: could not load" bug (?!) in the Fritz GUI I think.
Parent - By billyraybar (***) Date 2007-06-17 05:59 Edited 2007-06-17 06:43
Here is another image to look at.  Notice that the 'ponder move' (Ra7 in this case) is  stuck.  When the next ply is reached the ponder move will update and the kn/s will display correctly.
Parent - - By Vasik Rajlich (Silver) Date 2007-06-18 07:21
This is a sign that the GUI cannot keep up with Rybka's output. You'll need to tinker with various things in the OS or GUI. The simplest is to raise the GUI priority.

Vas
Parent - - By diskamyl (**) Date 2007-06-18 09:30
excuse me Vas, but at least half of the people here are using chessbase'd GUI's, Rybka most of the time gets paralyzed by getting to 0 kN/s and that's your solution? it's more of a joke to me. I've tried raising the priority and my computer slowed down so much that when I moved the mouse the pointer was moving in slow motion.

there's the best engine in the world in my computer but I cannot use it, what a shame. none of the other engines create this problem in those GUIs, and you're telling to "fix" the GUI or the computer or whatever. how about fixing rybka?
Parent - By Michael Waesch Date 2007-06-18 10:29
I agree. Raising the GUI´s priority is neither an elegant solution nor does it work at all. I only get these problems with the 32-bit versions and never experienced it with the MP 64 bit version. Weird, very weird.

Mike
Parent - - By Kapaun (****) Date 2007-06-19 14:07
I can only say again and again, that in my opinion it's not a real stop or breakdown, but just a bug in display. It's not like Rybka isn't calculating for some time...
Parent - By Jitugo (**) Date 2007-06-19 18:29
Hi Kapaun,

rybka might be calculating but it still leads to a loss of communication with the gui and as a result to losses on time. I watched the following game and  when it was rybkas 2.3.2 (white) turn with 16 seconds left on the clock the 0kns bug hit and it lost on time - this seems to me more than cosmetic:

[Event "Wertungspartie, 5m + 0s"]
[Site "Maschinenraum"]
[Date "2007.06.14"]
[Round "?"]
[White "lowrider1122, Rybka 2.3.2 mp"]
[Black "Vjps1993, Rybka 2.3.1 mp"]
[Result "0-1"]
[ECO "E32"]
[WhiteElo "2532"]
[BlackElo "2721"]
[Annotator "0.01;0.08"]
[PlyCount "136"]
[EventDate "2007.06.19"]
[TimeControl "300"]

{Rybka 2.3.1 mp: 16.2 ply; 471kN/s Intel(R) Core(TM)2 Quad CPU           @ 2.
40GHz 2898MHz, (4 threads), top2.ctg, àKE} 1. d4 {B/0 0} Nf6 {B/0 0} 2. c4 {
B/0 0} e6 {B/0 0} 3. Nc3 {B/0 0} Bb4 {B/0 0} 4. Qc2 {B/0 0} O-O {B/0 0} 5. a3 {
B/0 0} Bxc3+ {B/0 0} 6. Qxc3 {B/0 0} b6 {B/0 0} 7. Bg5 {B/0 0} Bb7 {B/0 0} 8.
e3 {B/0 0} d6 {B/0 0} 9. f3 {B/0 0} Nbd7 {B/0 0} 10. Bd3 {B/0 0} c5 {B/0 0} 11.
Ne2 {B/0 0} Rc8 {B/0 0} 12. b4 {B/0 0} h6 {B/0 0} 13. Bh4 {0.01/12 14} d5 {
B/0 0} 14. dxc5 {B/0 0} bxc5 {B/0 0} 15. b5 {-0.04/12 4} Qb6 {B/0 0} 16. a4 {
0.08/15 21} e5 {(dxc4) 0.08/16 25} 17. O-O {(Af5) 0.15/13 12} Qe6 {
(e4) 0.08/13 6} 18. Rad1 {0.17/12 13} g5 {(Rfe8) 0.21/14 3} 19. Bf2 {0.33/15 18
} e4 {0.23/19 15} 20. fxe4 {0.30/17 0} dxc4 {0.24/19 8} 21. Qxc4 {0.41/18 12}
Ne5 {0.21/19 3} 22. Qxe6 {0.40/17 2} fxe6 {0.26/17 2} 23. Nc3 {0.30/17 27} Nxd3
{0.31/19 20} 24. Rxd3 {0.32/18 19} Nxe4 {0.29/20 10} 25. Nxe4 {0.39/19 25} Bxe4
{0.33/21 11} 26. Rd6 {0.37/19 18} Rf7 {(Rc7) 0.35/19 20} 27. Be1 {0.44/17 15}
Rxf1+ {(Re8) 0.40/18 4} 28. Kxf1 {0.40/16 0} Re8 {(Bc2) 0.40/18 3} 29. Bc3 {
0.46/16 1} Re7 {(Kf7) 0.43/16 4} 30. g4 {(Ae5) 0.49/14 4} Bf3 {0.46/16 4} 31.
h3 {0.46/15 4} Kf7 {0.50/17 10} 32. Rd8 {(Rf2) 0.56/18 3} Re8 {0.48/19 4} 33.
Rd2 {0.49/17 5} Bd5 {0.47/19 9} 34. Ke1 {0.50/18 9} Re7 {(Rf8) 0.49/20 2} 35.
Be5 {0.50/13 3} Rb7 {0.58/19 3} 36. Rf2+ {0.55/16 2} Kg6 {0.53/19 1} 37. Rf6+ {
0.62/16 0} Kh7 {0.52/17 1} 38. Rf8 {0.63/16 0} Bg2 {0.58/17 2} 39. Kf2 {
0.65/16 2} Be4 {0.58/17 2} 40. Kg3 {(Th8+) 0.83/15 1} a6 {0.82/17 3} 41. h4 {
(bxa6) 1.52/15 1} gxh4+ {1.43/15 2} 42. Kf4 {1.52/17 0} axb5 {1.60/17 2} 43. g5
{(Rxe4) 1.59/17 12} hxg5+ {2.03/18 3} 44. Kxg5 {1.97/20 2} Rg7+ {2.18/21 0} 45.
Bxg7 {2.26/20 3} Kxg7 {2.18/21 1} 46. Rf4 {2.28/21 3} Bc6 {(Bd3) 2.31/19 1} 47.
axb5 {2.31/19 2} Bxb5 {2.42/21 0} 48. Rxh4 {2.33/21 1} c4 {2.44/21 4} 49. Rh2 {
(Th1) 2.72/21 1} Bd7 {(Ba4) 2.54/18 2} 50. Rc2 {(Td2) 2.48/14 0} Kf7 {2.36/21 3
} 51. Rxc4 {3.82/24 1} e5 {2.36/26 0} 52. Rc7 {(e4) 3.82/26 9} Ke6 {2.36/26 2}
53. e4 {3.82/19 0} Kd6 {2.36/24 0} 54. Ra7 {3.82/20 0} Ke7 {(Ke6) 2.36/27 3}
55. Rb7 {3.82/16 1} Ke6 {(Kd6) 2.36/21 0} 56. Rb1 {(Tb6+) 3.82/21 3} Ke7 {
2.36/29 2} 57. Rb6 {(Th1) 3.82/24 0} Bc8 {2.36/26 2} 58. Rb8 {(Tb5) 3.82/23 1}
Bd7 {2.36/28 2} 59. Rb1 {(Ta8) 3.82/22 0} Ke6 {(Bc8) 2.36/23 2} 60. Rb6+ {
3.82/24 0} Kf7 {(Ke7) 2.36/26 1} 61. Rb2 {(Ta6) 3.82/21 1} Bc8 {(Ke6) 2.36/28 2
} 62. Rb8 {(Tf2+) 3.82/26 1} Bd7 {2.36/18 1} 63. Rh8 {(Ta8) 3.82/29 0} Ke7 {
(Ke6) 2.36/19 1} 64. Rh7+ {(Ta8) 3.82/27 1} Kd6 {(Ke6) 2.36/27 1} 65. Rf7 {
(Th6+) 3.82/16 1} Ke6 {2.36/20 1} 66. Rf2 {(Txd7) 3.82/21 0} Ke7 {2.36/27 1}
67. Rh2 {(Tb2) 3.82/19 2} Ke6 {(Bc8) 2.36/28 2} 68. Rh6+ {(Ta2) 3.82/28 3} Ke7
{Zeit  (Lag: Av=0.20s, max=0.4s) 2.36/23 1} 0-1
Parent - - By Jitugo (**) Date 2007-06-18 10:15
Hi Vas,

Basically that behaviour is not  present with 2.3.1 nor is it with any other engine. The fault might lie with the gui, but as popular as that gui is, wouldnt it be nice if rybka just worked with it? Also i tried all possible priority combinations and still had the problem. Also i noticed that some of the times when this problems occurs one of the two rybka processes (dual core) is only at 10% while the other is maxing out its cpu (this is not very reproducable though - 2 out of 7 tries). Maybe you have mercy with us Fritz GUI 10 users and solve this prob once and for all ...

regards,

Jitugo

P.S.: 2.3.2 is much better than 2.3.1 in general. Only 3 bugs to go: 0 knps, absurd pondering and erratic zugzwang behaviour
Parent - - By er (**) Date 2007-06-18 11:10
... and You have mercy with us ChessBase 9 users!
Here it is the same problem.

It never happened before,
and I used all Rybka versions since Dec 2005.

EGR
Parent - - By Vasik Rajlich (Silver) Date 2007-06-19 12:09
0 knps is not a problem. Rybka will sometimes put together the first set of PVs purely from the hash table and no nodes are searched at all.

Losing on time is a sign of a problem. The Chessbase GUIs are getting overwhelmed by these 0-node PVs and somehow it can take them a really long time to catch up.

I could add to Rybka an option like "oversuppress PVs". This is really the wrong type of solution, though. Please try tinkering with your setup to make sure that the GUI has enough CPU time to handle its work. I can also suggest setting Rybka's "CPU Usage" to 95 (for example), again to give the GUI more time. Perhaps Chessbase support could also suggest ways to 'streamline' the GUI operation.

Vas
Parent - - By Jitugo (**) Date 2007-06-19 14:02
I it depends on what you call "wrong" about adding a parameter which would enable rybka to work without hassle in chessbase gui:

1) if you want to sell less rybkas to people using the most popular gui playing on playchess, then yes such a solution would be wrong

2) If you call tinkering with process priorities something your customers should deal with (and i never got it to work with any priority setting, be it for the rybka processes or the gui process), then yes its wrong

3) if you really think chessbase would care about ryba working in their interface, then yes chessbase should change the gui.

4) If you really think that loosing games and rating points on playchess due to loss on time does yourself a favour, then yes this is the "wrong" solution

I think the "wrong" solution is the right choice for everybody, your customers, your sales, rybkas reputation....

regards,

Jitugo

P.s.: Of course from a purely software engineering standpoint it might indeed be wrong - but this is the real world
Parent - - By Vasik Rajlich (Silver) Date 2007-06-21 12:36
I'll need more information about this problem. Is it an obscure problem which happens with misconfigured systems? Or is this a regular problem with the Fritz GUI? I also use the Fritz GUI on occasion and haven't seen it.

Vas
Parent - - By billyraybar (***) Date 2007-06-21 19:47
Can someone please help me troubleshoot this problem??  I have tried raising GUI priority (above normal as well as high) and also reducing Rybka priority with no success.   My system:  Amd 4200+ dual processor, Rybka 2.3.2a mp 64 bit, windows xp x64, 2 gb ram (Buffalo technology ddr pc3200/400 mhz), msi k8n sli-f mainboard with nothing overclocked - using Fritz 10 GUI, have tried Fritz 9, Zap x64 all with no success.  I'd also like to say that I have no non-essential processes running when I experience the forementioned problem.  Is there a way to track down the source of the problem?? Additionally I tried reducing Rybka cpu usage and it had no effect!! I reduced it down to 75 and it didn't matter.  
Parent - - By diskamyl (**) Date 2007-06-22 06:17
no. I've got the same problem and no one cares.
Parent - By Michael Waesch Date 2007-06-23 07:17
Since I currently run 2.3.2 vs 2.3, I had the opportunity to see that 2.3 has the same mysterious kn/s drop. But 2.3 seem to more frequently update the display, so one can see that it is not stuck and still works. And then, exactly like 2.3.2, it gains back full kn/s display when a move is made.

After thinking quite a while over it, I am pretty sure that I see the same effect with Deep Shredder, which is also of pure cosmetical nature. When I have the time, I will run a couple of games on ICC using Arena and see if this happens there too.

Mike
Parent - - By Vasik Rajlich (Silver) Date 2007-06-25 13:53
There are several things mixed together. Please describe precisely the problem and what you tried to do to correct it.

And please note: 0 knps (or 0 nodes searched) is not a bug, it's a feature :) Rybka will often go to fairly high depths purely from her "memory", without searching any new nodes.

Vas
Parent - By Kapaun (****) Date 2007-06-25 15:09 Edited 2007-06-25 15:22
Yes, it is, like I said, cosmetic. People see a 0 KN - and because in fairly high depths this stands there for quite a while until the first move is searched and an update is there, they get hysteric and believe that Rybka is stuck. Which she isn't. There are programs (for instance I noticed that today with Shredder) which give a provisional update when they run into a move which will cost them lots of time. It's basically not more than saying "Hey I'm here, I'm still living, stay tuned..."
But in certain situations this can be interesting information, though. For instance when you just want to know if this new move is going to replace the old one or not, and don't care about the details now. Maybe it would be a solution for Rybka, too.

By the way, it doesn't seem to be obscure or exotic. I get it, too, regularly with the Fritz 9 GUI (HIARCS version).
Parent - By billyraybar (***) Date 2007-06-25 15:31
What a wonderful feature! ;) Thanks for the assurance, Vas.    
Parent - - By Jitugo (**) Date 2007-06-25 16:18 Edited 2007-06-25 16:28
Hi Vas,

If this is supposed to be a feature, how comes rybka looses on time when this hits? See the game i posted earlier in this thread. I can fairly certain rule out a misconfigured system, as it happens both on a AMD dual core and an INTEL CORE 2 DUO - even though the problem is not easily repeatable. . Also i know of NO combination of priorities/cpu usage of ryba and/or the gui which solves the problem - and believe me i tried a lot. I personally think that the stalling of the gui/rybka communicaiton could be avoided by a simple change to rybka (much more likely than chessbase changing their gui for rybka) - do it like shredder UCI (which always works) and update the nodecount immediatly (any figure will do take 0) and then update the nodecount every second or so independently from the main line. This way the chessbase gui won't stall.  What happens if rybka time is low and her time-algorithm comes to the conclusion to move in lets say a second and rybka is busy with reconstructing a line purely from hash. If that could take longer than a second ( And i have seen cases where this takes 30 secondes in a blitz game) there you have the reason for the bug. If this scenario is impossible, than there is another bug in time management.

regards,

Jitugo

P.S.: Yes Kapaun, we know that you just unconditionally love the 0kn/s behaviour, please do not respond again.

Parent - By Kapaun (****) Date 2007-06-25 17:08 Edited 2007-06-25 17:12
Maybe you should revert your GUI version to the one from December 2005. Losing on time is a well known behaviour for UCI engines on the CB server if you use the newer GUI versions.
Also, you should go to "Engine parameters" before loading Rybka and activate the "Server Buffer" option.

Best regards and happy hunting
Kapaun
Parent - - By Vasik Rajlich (Silver) Date 2007-06-27 13:27
Hi Jutigo,

reconstructing the PV from the hash table takes much much much less than a millisecond.

If Rybka is losing games on time on your machine, then something else is wrong. There is any number of candidates for this - for example, the computer may be busy with other things. There are also ways to "deactivate" the Fritz GUI by accident, I am not familiar with all of them. There is no Rybka 2.3.2a change which could make her more likely to lose on time, at least as I understand the topic.

Vas
Parent - - By Jitugo (**) Date 2007-06-27 17:37
Hi Vas,

well fact is that for a long time the gui does not receive any moves from the rybka processes and then suddenly you get multiple iterations at once  - so it seems there is no communication for a long time while rybka calculates and reaches further depths  (e.g. depth 15, depth 16 and depth 17) then suddenly the gui "catches" up and displays all lines almost at once. if during the time the gui does not communicate with rybka, rybka wants to move well nothing happens hence rybka might looses on time. As this never happens with other UCI engines (e.g. shredder) something rybka does must be different from shredder. I am under the impression that i am not the only one with this problem, in fact many people told me or posted here that they have the same problem....

regards,

Jitugo
Parent - - By Vasik Rajlich (Silver) Date 2007-06-29 13:32
This is a different problem.

If Rybka waits for a while and then sends two or more PVs together, it means that your GUI is starved of CPU resources. It's possible that this happens a bit more to Rybka than to other engines, because when Rybka runs in MP mode the child processes never idle. Anyway, this is certainly not new in 2.3.2a.

Vas
Parent - - By garyf919 (**) Date 2007-06-30 02:32
Hi Vas,

Firstly, congratulations on all your recent and past acomplishments with Rybka!
They are truely outstanding in the field of computer chess and software development!

On another note, there seems to be a number of queries regarding Rybka 2.3.2a
with regard to maybe annoying or even cosmetic issues.  I think what people may
be politely suggesting is that there will be a Rybka 2.3.2b that cleans these things up.
I know that you stated previously that there would only be a 2.3.2b if there were
any serious issues with 2.3.2a, but I think that such a clean-up release would go a long way
for your customers, especially if the distance to Rybka 3.0 is a long way out (like year end).
I'm sure a final clean-up release would be a simple matter for you after your schedule
frees up a bit. No? BTW, It's really called customer satisfaction :)

Respectfully, from a 29 year software developer and executive software manager.

Gary
Parent - - By h1a8 (***) Date 2007-06-30 06:50
But Vas don't know what the exact problem is, as he has never experienced it.
He already stated that the 0kn is not a bug but a feature.
So for Vas to clean up 2.3.2a would assume that there is a bug and that Vas sees it. The former might or might not be true but the latter isn't.
So in other words, if he doesn't see a bug then it is impossible for him to clean it up.
Now I'm sure Vas has been trying to reproduce these problems some are saying to have (losing on time) but with no success.
So it may be best to wait for Vas to find the problem (if there is one) or just keep providing him with specific information in order for him to try to reproduce the problem.
But trust me (or logic), one can't clean or fix what one doesn't see to clean or fix.
Parent - By Vasik Rajlich (Silver) Date 2007-07-01 16:11
Of course, it goes without saying that if there is a serious bug, then we'll make an update.

Vas
Parent - - By Jitugo (**) Date 2007-06-30 11:05 Edited 2007-06-30 11:07
Hi Vas,

VAS: This is a different problem.
VAS: If Rybka waits for a while and then sends two or more PVs together, it means that your GUI is starved of CPU resources.
VAS: It's possible that this happens a bit more to Rybka than to other engines, because when Rybka runs in MP mode the child processes never idle.
VAS: Anyway, this is certainly not new in 2.3.2a.

finally we are getting somewhere. If this is not new to rybka 2.3.2a but has been a problem of all rybkas i hope you consider fixing it even more. The bug is hard to catch because you have to watch the game live. One can not see it easily from the saved game.  I only noticed it with rybka 2.3.2a but maybe you are right, it could have been there all along. But one thing remains a mystery to me, why does this only happen to rybka and not to other uci engines? Do they do a small pause when updating a pv (a couple of ms) so the gui can catch up? Why dont you implement something similar in rybka? Is it just a matter of "softwareengineering ethos" or would it be difficult to implement in rybka? Or do you reckon with the new rybka gui nobody should use the chessbase gui anyway? Will the new rybka gui be able to play in the engineroom on playchess.com.

regards,

Jitugo
Parent - By h1a8 (***) Date 2007-07-01 02:17
"The bug is hard to catch because you have to watch the game live."

No you don't. Remember that you said Rybka will lose on time (This is easy to see after the game). Since this is the only problem some are saying to have,
then Vas should first find a game where Rybka lost on time on his machine(s) and then try to reproduce the game (with same opening, hash, time, everything)
to try to find out why Rybka lost on time.

In other words, after Vas find such a game then and only then should he look at the live game by reproducing.
Otherwise, he could have looked through many live games with no success in spoting the problem. And this would have wasted
precious time that Vas could have otherwise used to prepare for a maybe Junior match, ppc Rybka, linux Rybka, Rybka 3.0, etc.
Parent - - By Vasik Rajlich (Silver) Date 2007-07-01 16:10
I seriously doubt that this only happens to Rybka. The only possible reason is that maybe in MP mode she never idles the child processes. Are we talking about the MP version?

This problem by the way can be fixed with (among many other things) the "CPU usage" parameter.

Vas
Parent - - By Svilponis (***) Date 2007-07-01 19:03
The problem appears in case of calculation on single core CPU too. Setting priority of GUI from task manager does not help at all. I can not remember if I have ever seen this problem with Shredder. I'm almost sure thad I am not.
Parent - - By Svilponis (***) Date 2007-07-02 23:12 Edited 2007-07-02 23:18
Attached screenshots show the "zero nodes bug" in its full beauty.
I was researching certain line using my notebook (Pentium M 740), Shredder as GUI, Rybka 232a 32 bit as engine, 150 MB hash (500 MB total RAM), infinite mode. I inserted moves manually and while moving backwards let Rybka to calculate couple of minutes at each position, where I thought that there might be alternative moves available. I was interrupted by other duties. When I returned, the computer was calculating one position almost 3 hours already. I inserted calculated main line and found, that zero nodes bug appeared. I decided to follow how long it takes for Rybka to show some line. When I recognised, that this time it takes unusually long, I decided to make a screenshot. Please note, that there is no proposed move for already 72 minutes!
And it still continued! When I forced engine to make next move, the results appeared again (screenshot2).
As you can see from Task Manager Window, there was enough free RAM and no swapping occured.
Attachment: zeronodesbug1.jpg (234k)
Attachment: zeronodesbug2.jpg (243k)
Parent - - By Vasik Rajlich (Silver) Date 2007-07-03 18:32
Your screenshots look normal.

Note also that my above message was about Rybka losing on time. I acknowledge that Rybka can:

1) Report many PVs with node counts of zero (no searching is done in this case)
2) Take a while to report the first PV with a non-zero node count

Vas
Parent - - By Svilponis (***) Date 2007-07-03 19:29 Edited 2007-07-03 19:33
IMHO the "losing on time" problem and the "not reporting the first PV" problem have the same roots.
I think, that although "not reporting the first PV" in infinite analyses mode does not cause losing on time, it is still very annoying.
If I analyse a line and enter a move, I want to see very soon what is the move that Rybka suggests and what are Rybkas quick estimations for some stronger alternative moves. I don't consider to be normal to stare blank screen for hours.
Parent - By Vasik Rajlich (Silver) Date 2007-07-05 11:46
Yes, I understand.

In 99.9% of cases, Rybka will first display PVs from the hash table (with node counts of zero). However, I have also myself seen cases where the first PV takes some time. If you are really impatient, I suggest that when you don't see a PV after a couple of seconds, clear the hash.

This will be cleaned up in Rybka 3.0.

Note also that this will only happen during analysis, never during game play.

The losing-on-time is a completely separate issue. It happens when Rybka or the GUI do not get full CPU resources. So far I see no reason to think that anything Rybka does makes this problem worse.

Vas
Parent - - By Lukas Cimiotti (Bronze) Date 2007-07-01 21:56
I can't reproduce this problem on all of my computers. In fact, on my computers, Rybka never lost on time since Rybka 1.2 came out - yes Rybka Beta 1.0 had a real problem - it quite often lost on time. But this has completely changed since then. One Problem might be: did you choose hash tables, that are too large for your computer? As soon as the computer starts swapping, everything goes down the drain. If you have got only 1 GB of RAM, don't use more than 256 MB for hash, for 512 MB it should be no more than 128 MB.
Parent - - By h1a8 (***) Date 2007-07-02 02:23
Very good.
As I want to agree that please use 1/4 of total memory to hash especially if playing engine vs. engine matches on one computer.
Parent - By M ANSARI (*****) Date 2007-07-02 05:29
Yes hash setup is quite important.  You should also multiply the amount of memory required as you go up in cores because each core will then chew up more hash.  In engine matches make sure you multiply that again by 2 since each engine will use its own hash. 
Parent - By Vasik Rajlich (Silver) Date 2007-07-03 18:33
Yes, this could cause the problem.

One of my test methods is to take a testsuite of several hundred winning positions and make sure that Rybka can win them all against various opponents and at various time controls. On my computers, she is always 100% successful.

Vas
Parent - - By Graham Banks (*****) Date 2007-07-02 09:08
No problems in CCRL testing to date with Rybka 2.3.2 32-bit 1CPU under Chessbase GUIs.
It's a monster!   :)

Regards, Graham.
Up Topic Rybka Support & Discussion / Rybka Discussion / Is the Zero KN/S Cosmetic?
1 2 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill