Author: Lars Bremer
Date: 12:24:52 01/11/04
Go up one level in this thread
On January 11, 2004 at 14:17:26, Eugene Nalimov wrote: >On January 11, 2004 at 14:01:55, Lars Bremer wrote: > >>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 > >I have one system with SCSI U320 controller and two hard drives plugged in -- >U160 and U320. According to specifications those drives have similar seek times. >U320 drive consistently outperforms U160 one in disk-heavy activities (TB >splitting, compression, copying, verification, etc.) Ok ok, I believe you :) I did measure only once, it is a logn time ago with a prototype of an U320-Controller and a maxtor drive with beta-firmware. I found only very small differences. btw: I am not sure that similiar drives have the same firmware in the U320 and the U160 version. :) greets, Lars > >Another good test is program start time in the presence of lot of TBs. I believe >Bob reported *very* good start time for his system... > >Thanks, >Eugene
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.