If you know SCSI

[brazilio]

hardware raid cards aren't particularly expensive, promise makes some pretty good ones, 3ware as well although if I remember correctly 3ware either stopped making 32-bit cards, or just stopped making 32-bit IDE cards. And of course, adaptec makes some good ones as well. But really, hardware raids are pretty overrated when your CPU/RAM isn't going to be fully tasked towards serving something else. The only reason I'd lean towards a hardware raid is if, like you're talking about, I'm going to be using another OS where the software raid just won't function or if I want a braindead solution where I won't have to instruct somebody how to resync a new disk.

[Terry]

It’s been so long since I’ve used a ramdisk I didn’t even realize that Microsoft no longer includes it. Bah. The ramdisk.sys in Windows now is just an “outline” of what an actual driver might look like. WTF.

Oh well. Next step. Just for the heck of it I ordered an LSI Logic LSI8951U Ultra2 LVD SCSI Card, Western Digital 9.1GB Ultra2 10K RPM SCSI Drive, and cable, all for $45. Can I shop or what. [img]/images/graemlins/smile.gif[/img] Not high end stuff but it should be enough to firmly convince me whether or not ...

If it makes a noticeable difference I’ll come back and gloat. If it doesn’t, I’ll just keep quiet so I don't have to read all the "I told you so" posts.

[astroglide]

you wasted your money. that hard drive is ancient and it would be retarded to compare it to anything.

http://faq.storagereview.com/tiki-in...ormanceFactors

[ QUOTE ]
in the end, a drive's interface (ATA, SATA, SCSI, SAS, etc) has little effect on its performance. Like spindle speed, an interface exerts its effects more through manufacturer and market positioning. Note that while SCSI drives are undoubtedly more expensive than their ATA counterparts, they are not necessarily faster for non-server use. In fact, the safe rule-of-thumb is that given equal spindle speeds, a current-generation ATA drive will be faster than a current-generation SCSI unit.

[/ QUOTE ]

...and yours is not remotely close to a current generation drive. western digital hasn't manufactured a scsi drive in years.

[Freakin]

You need one of those scsi cards with a 10-led light bar. those are awesome.... too bad my only machine that ever had EISA died, otherwise mine would still be running.....

Freakin

[Terry]

astroglide, let me make one thing clear right off the bat – I don’t doubt at all that you already know more about disk drives than I will ever know. That point is not in question. I am not disagreeing with you, I am trying to understand why you say what you say and where my thinking is going wrong.

It is my understanding that a SCSI system uses a chip on board the controller to control disk access and an IDE drive uses the CPU. We see this evidenced when CPU usage goes to 100% during database accesses. What I am reading on the link you provided is that the SCSI controller will eliminate much of that CPU usage. Am I wrong about that?

My current hard drive has a seek time of 8.9ms. The old SCSI drive I ordered has a seek time of 5ms. My current drive spins at 7200 rpm. The SCSI drive spins at 10000 rpm. Don’t these speed differences in themselves mean that the time it takes for the database updates will be significantly reduced simply because the drive is faster – even if I am wrong in my understanding of CPU usage?

Keep in mind that my only objective is to minimize the time that the CPU is pegged at 100% during PT database updates. I am not questioning whether SCSI in general is “better” than IDE for a typical computer user or whether the difference is “worth it.” I am only trying to determine whether or not it will minimize CPU usage during database updates.

Where am I going wrong?

[fluxrad]

If your CPU is pegged, then you're most likely not IO bound. You might check your data transfer rates to make sure you've got things like UDMA enabled (sometimes this gets shut off for one reason or another).

It really sounds like your box is just having trouble crunching the numbers on PT which isn't going to get fixed by a SCSI system, unless you also throw quad Xeons behind it.

Methinks those "database updates" are PT doing all kinds of B-Tree inserts, indexing, etc. Get an Athlon 64 and some SATA drives and be happy w/ the performance you get there


Just my .02

[hicherbie]

[ QUOTE ]
The real trick to speeding up pokertracker is to get away from access databases.

[/ QUOTE ]

seriously, why sql isnt used still baffles me.
as far as how scsi performs with pt now...im running an x15 and performance is better than with a 7200, but it seems only slightly faster than my buddys 10k raptor. so it probably wouldnt be worth the extra money for just pt use.

i think its just pretty crushing to access that much data at one time...hardware upgrades wont get you there much faster.

[astroglide]

scsi cpu utilization under real load is going to be better than ata, but both are still in the low single digits in terms of percentage overhead (read: generally irrelevant). try copying your pokertracker database to your desktop using your ata drive. does your cpu utilization go insane then? the load isn't being generated there. pokertracker does name queries and misc preparation each time it is loaded (as evidenced by the xxx of xxx loading at the bottom of the screen).

for seek/rpms look at http://faq.storagereview.com/tiki-in...ormanceFactors again. #1 is firmware/buffer. for non-server usage the buffer is where most things are going to be read (this could be spelled out better on item #3, it isn't extremely clear for casual readers). random seeking is only a priority concern on high-performance servers where all kinds of data from all kinds of points on the disk are accessed simultaneously. desktop multitasking does not generate that kind of load. this is also the only point where command queueing begins to matter.

[mason55]

You can buy a solid state HD with a 3.5" interface.

If cost isn't a huge deal this is by far the best bet.

[Terry]

Everything is talking about non-server usage. Maybe that’s my point. I’m thinking that the act of repeatedly reading and writing to a large number of non-sequential disk locations as the database updates makes this application come closer to server usage than to typical home computing.

For typical home computing, game play, file transfers like CD burning, stuff like that, the nature of the disk activity is mainly sequential reads and writes. When it comes to the PT database updates, the nature of the disk activity requires a great many seeks, both for reading and for writing – just like a server.

That’s what’s leading me to believe that the faster seek time, faster spindle speed, and the (perhaps) superior algorithms of SCSI should make a very noticeable difference.

Ah well. Mayb my little $45 experiment will teach me something. Believe it or not, I really do like learning new things.

Thanks for your input.

BTW, to those who mentioned it, PT will soon be switching to PostgreSQL.