Author: Robert Hyatt
Date: 11:39:07 03/09/04
Go up one level in this thread
On March 09, 2004 at 00:07:10, William Penn wrote: >On March 08, 2004 at 23:52:53, Slater Wold wrote: > >>On March 08, 2004 at 23:49:58, William Penn wrote: >> >>>Pretty simple. Reduce hash size. That's the only thing I've found to have a >>>significant effect when tablebase access starts to churn the hard drive >>>constantly. Engine speed (kN/s) falls dramatically at that point, perhaps to 10% >>>or less of normal speed, and never recovers. However using smaller hash size >>>appears to fix this problem. >>> >>>For example my computer has 1G RAM installed. I can run Shredder 8 with 768MB >>>hash normally, although I often use 512MB which the op system prefers a bit >>>more. Now one would think that 512MB hash would be OK in any situation with 1G >>>RAM, but not so. It's too much hash when tablebase access starts to crank up >>>heavy in endgame situations. At that point, reducing hash size to 256MB usually >>>fixes this problem, restoring engine speed to a reasonable kN/s. I haven't yet >>>found it necessary to goto 128MB hash. >>> >>>[Windows XP Home, Athlon XP 2400+/2.0GHz, 1G RAM] >>>WP >> >>Your HD is 'churning' because it is access a database on your hard drive. >> >>Your nps drop because the engine has to wait on info from your hard drives. >> >>The 'churning' is not a problem. Your HDs are. >> >>Go SCSI. Or at the very least, 10k SATA. > >Churning IS a persistent problem! How can you say it is not the problem? Of >course it is the problem! All you have to do is sit here and watch the hard >drive activity light, and listen to the drive churning constantly. Access never >stops. > >My hard drives are NOT a problem! There is nothing wrong with them nor my >computer. I have two 7200rpm Maxtor drives, 120G and 80G. And the windows >pagefile is also optimized on its own dedicated partition. Maxtor drives are not fast. The suggestion to reduce hash has a good and bad side. Good in that it allows the O/S to cache more of the tables in memory for you, avoiding your slow disks. Bad in that making the hash smaller adversely affects performance in the opening and middlegame before tables are needed... Best solution is just more memory so you can have a reasonable has size and the O/S can have a reasonable filesystem cache as well... > >Sorry but I know nothing about SCSI. If that would require buying different hard >drives, then it's not an option for me. >WP
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.