If you know SCSI

[astroglide]

your database is one large file which will be stored in a contiguous segment on a properly defragmented hard drive. reads and writes done to it should be in a very localized physical zone, with the actuator not having to travel any signifigant distance.

[Terry]

I defrag daily with PerfectDisk 7. All files are packed to the front of the drive leaving no empty spaces and the PT database files is always last since it changes the most frequently. The database file fragments immediately upon use, probably on the first import.

Maybe this is where is my understanding of how a drive and a database operates begins to be inadequate. I don’t really know how much seeking the drive needs to do for a file that is fragmented but still physically close together. I also don’t know how much jumping back and forth between the physically separated hand history file and the database file PT does.

One more thing that I don’t understand at all. It appears from the PerfectDisk display of the file locations that the newly fragmented sections of the PT database are not being written to the next available sector on the disk but are instead being written to the end of the disk. I’m not sure that I am interpreting the graphic correctly, since I thought Windows always assigns the next available free space for writes. Time to bury DOS and study up on the MFT Zone and NTFS, I guess.

If the updated sectors are actually physically distanced from the rest of the file then the seeks are certainly increased, with each seek being to the physical end of the disk rather than to a nearby sector. This enforces my thinking that the multi-tasking of poker resembles server usage more than it resembles typical home computer multi-tasking.

[Terry]

The results are in. SCSI drive made no noticeable difference in CPU usage. Some of you already knew that.