Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: A second question ... Tablebases!

Author: Lars Bremer

Date: 11:01:55 01/11/04

Go up one level in this thread


On January 10, 2004 at 16:22:25, Robert Hyatt wrote:

>On January 10, 2004 at 12:13:20, Lars Bremer wrote:
>
>>On January 10, 2004 at 11:51:46, Robert Hyatt wrote:
>>
>>>On January 10, 2004 at 11:30:52, Lars Bremer wrote:
>>>
>>>>Hi,
>>>>
>>>>>I have to buy a new OS :-((
>>>>
>>>>Win2k does support HT. It handles HT as two different physical processors. WinXP
>>>>can handle these virtual processors.
>>>>
>>>>>The biggest wish is a good Service Pack for Windows NT4 (SP7) with USB, >Directx9
>>>>>and Hyperthreading support! That's all :-)
>>>>
>>>>It exists and is called Windows XP
>>>>
>>>>>BTW:
>>>>>Bob do you think that SCSI is better as S-ATA (interesting for me if I used on
>>>>>two harddisk 5-pieces for engine-engine matches with ponder = on on dual Xeon.
>>>>>After my first test it seems that S-ATA is just great for tablebases.
>>>>
>>>>Lol, SATA-drives are exactly the same as PATA-drives, there are no differences.
>>>>I count them twice, believe me.
>>>>Normally there is only a special chip at the drive's board to convert parallel
>>>>to serial.
>>>>
>>>>If you want to know which kind of drive is better to store and use tablebases,
>>>>you should read CSS 4/03, where I compared some different hard drives under this
>>>>point of view.
>>>>15k-SCSI was the best, but it was not as fast as one could think, and modern
>>>>ATA-drives are very fast too.
>>>
>>>SCSI drives offer far more than the IDE and IDE-followon SATA drives.
>>>
>>>(1) 320mb/sec burst transfers, double SATA, 2.5X IDE.
>>
>>You talking about the protocol, not about the drives. The fastest SCSI-drives
>>can transfer around 75 MByte/sec, the fastest IDE-drives are close to 60
>>MByte/sec now.
>
>We are talking two different numbers.  I'm talking peak burst transfer from
>on-board cache to main memory.  Not sustained data transfer rate for long
>reads.

Yes, of course. But the peaks have nothing to do with the real life performance.

>If you think your IDE drive is within 20% of a 15K scsi drive, we can run a
>benchmark to compare them. Every time I have done this, IDE simply gets
>blown out of the water...

May be you ran the wrong benchmarks. We are talking about tablebases. And here
is the advantage of a SCSI drive not as high as the technical parameters like
seek time and transfer rate would suggest. I tested it with a complete set of
5-men-TBs. I tried following drives:

drive			rpm	cache [kB]	seek time [ms]	transfer rate [Mbyte/s]
U320 Fujitsu MAS3735NP	15000	8192		4,4		70,8
UDMA6 Samsung SP1604N	7200	2048		10,8		43,5
UDMA5 Fuj. MPG3204AH-E	7200	2048		11,0		32,7
UDMA4 Maxtor 33073U4 	5400	512		13,4		21,7

I let some programs solve some positions and picked the time. A typical result
was:
			depth 14	Matt in 13	Matt in 12
U320 Fujitsu MAS3735NP	00:37	        01:24	        04:45
UDMA6 Samsung SP1604N	00:46	        01:35	        05:08
UDMA5 Fuj. MPG3204AH-E	00:54	        01:45	        05:31
UDMA4 Maxtor 33073U4 	01:24	        01:45	        06:31

this was only one program in one position (5R2/5br1/8/4b1B1/8/3k3K/8/8 b - -).
Not too impressive, the SCSI-rocket.


>And it doesn't totally hang the system while the
>drives are busy either.
>
>
>>
>>>(2) tagged command queueing
>>
>>tagged command queueing  is *not* an SCSI-feature. IBMs IDE hard disk drives can
>>do that since a lot of years. Unfortunatly there is no IDE-driver to handle
>>this. :)
>>
>>
>>>which offloads the "optimizing" stuff from the
>>>I/O request handler and lets the SCSI controller handle multiple requests in
>>>the best possible order, something a request handler can hardly do since disk
>>>drives like to "lie" about their geometry due to various compensation zones.
>>>
>>
>>>(3) run on a SCSI and IDE system side by side.  Do something HUGE in terms of
>>>I/O on both.  The scsi system will feel perfectly normal.  The IDE system
>>>will basically "freeze".
>>
>>It depends. In a server system with a lot of small I/Os, may be. In your
>>computerchess- and desktop-pc, nevermind.
>>
>>>There is little to recommend IDE or SATA except _price_.  That is where its
>>>only advantage is seen.
>>
>>So you must be deaf! I never want to have a 15k-SCSI under my desk :)
>
>I have 7 of them and they don't make much noise.  The Case fans are far
>noisier.  I can barely hear the drives.  In fact, I don't notice any
>difference in the 15K drives and the older 10K drives, I have both side-by-
>side.

May be you are too old to hear the high frequent whistling of an 15k drive ;)
In fact you need a fan for SCSI drives. ATA-drives don't need an additional
cooling. And, your desk must vibrate when your 7 SCSI drives are seeking...


>
>>
>>>But I want performance.  And for endgame tables, the
>>>faster the better.
>>
>>So you did measure it? What is most important? latency, transfer rate, any
>>other?
>
>Latency _and_ transfer rate.  15K offers the best latency by a factor of 2.
>Transfer rate is next...  U320 SCSI wins there as well.

Well, latency is not the only parameter to describe the seek time. The time to
move the heads between the tracks is a part of seek time too. I do not think
this seek time is the main important factor for TB-access. I tried it with a
test position with the samsung drive, once with acoustic management=fast (seek
time=10,8 ms) and once with acoustic = quiet (seek time = 12,3 ms). There is a
differenc around 10 percent. The time to solve some positions was nearly the
same...

>>>15K drives are great, U320 15K drives are even better.
>>
>>If you use only one drive there is no difference in speed between U160 and U320.
>
>I disagree, although I have not specifically tested that.  But U320 disks
>are out-performing U160 disks in two machines I have sitting side by side.
>IE just doing a disk-to-disk copy of a large file...

So you use U320 drives with an U160-controller? Come on. If the drives are
different, your "out-performing" says nothing. But this is very off topic.

greets

Lars



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.