Author: William Penn
Date: 21:27:08 03/08/04
Go up one level in this thread
On March 09, 2004 at 00:11:54, Slater Wold wrote: >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. > >That's what TBs do! That's not the problem! > >>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. > >The average seek time on a Maxtor DiamondMax Plus 9 is about 9.3ms. > >The average seek time on a Seagate U320 15k RPM SCSI drive is about 3.6ms. > >Effectively 3x faster. > >>Sorry but I know nothing about SCSI. If that would require buying different hard >>drives, then it's not an option for me. >>WP > >You would have very little drop in nps with the SCSI drive. But the 'churning' >would persist. The 'churning' is part of HD access. It sounds like SCSI drives would help, but I'll probably be using these IDE/ATA's for the next several years. I'm also not sure if my Compaq Presario S4020WM computer/motherboard/bus/etc could handle SCSI drives. I know nothing about such technical things. So alas hardware changes aren't much of an option here. You say it's a hard drive problem. I say it's a churning problem, but those are just the opposite sides of the same coin. The problem/fact is that the hard drive is being put under extreme stress (which I dub "churning") and thus engine speed falls dramatically in endgames. I suppose it's some kind of competition between the hash table and tablebase cache, both competing for their share of the pagefile, but I don't know. For other people who are in a similar hardware boat and situation as me (probably 90%+ of folks), the only solution is apparently to reduce hash size. After playing around with these things for several years, that is the ONLY thing I've discovered that helps significantly to increase engine speed again after it drops due to heavy tablebase access. Changing tablebase cache size seems to have little effect. 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.