SCSI Disk Performance vs XP Pro Client IDE Drive

[Craig W]

There may be a straightforward answer to this Q., however it has me puzzled as I would have thought Ultra320 SCSI 10K disk performance would outdo a slower 7,200 ATA-133 drive.

I have traced a slow server Database application to a disk write bottleneck on the following system: ML370G4 Windows 2003 Server, with 3.6Ghz Xeon, 1GB RAM, 642 Smart Array Controller and 2x 146.8-GB Plugable Ultra320 SCSI 10,000 rpm Hard Drives.

I originally had the disks set-up in RAID 1+0 however for the purposes of testing, and to eliminate the array factor from the equation, I converted to single RAID 0, 128KB (default) Stripe disk.

The slow performance only occurs during one command in the Database application (Posting operation that takes newly entered orders and changes their status flag from 'E' to 'O'pen Orders). Its taking ~10 minutes to complete for RAID 1+0, and ~8.5 minutes for the RAID 0. From what I can see the function involves continuous sustained writing to the disk for the majority of the 'posting' time. The post shouldn’t take more than 1 to 2 minutes.

I have done numerous tests using Windows perfmon on the ML370, and compared the results to a stand-alone Windows XP Pro system, with 1.5Ghz P4, 256MB RAM, Samsung 80GB 7,200 ATA-133 Drive. The same application software set-up was employed on both systems.

The DB Application is designed to run over the LAN, however for the server performance tests I have run the application direct on the server console. From the numerous recorded parameters collected I believe the relevant ones are the Disk Writes/s, Bytes/s, and Disk %Time (Processor, Memory, and other resource thresholds are low).

ML370G4 Server:
Disk Writes/s = ~200
Bytes/s = ~900K
Disk %Time = ~98%
DB Post Time = ~8.5min

P4 System:
Disk Writes/s = ~790
Bytes/s = ~3000K
Disk %Time = ~30%
DB Post Time = 2.5min

As can be seen the P4 System is writing to disk at least 3x the speed of the ML370.

The P4 System's 7,200rpm IDE dive has a max. host to drive buffer transfer rate of 133MB/s and the ML370's 10K rpm SCSI has a max.rate of 320MB/s.

What is occurring here, shouldn’t the Ultra320SCSI + 642 Smart Controller combination be producing better performance than this, esp. compared to the less resourceful P4 System?

At less than 1MB/s transfer rate it seems the 320MB/s rated SCSI isn’t being used to capacity, however the Disk %Time indicates max.usage.

Can anyone please shed some more experienced light on this and suggest a possible solution.

Thanks, Craig.W

[e4services]

My vote, the 642 is the problem. My experience says RAID 0 or 5, you are still counting of the write control of the controller. Example is my desktop here, using an IDE RAID controller. It is REALLY slow.
Suggestion: Add an IDE RAID set up to your test to be fair. Then add a SCSI attached to the onboard SCSI controller and not the RAID. That should give you a good idea of the bottle neck.
As for the 642; In your case, I would go with the 128-MB BBWC (Battery-Backed Write Cache) Enabler, if you do not have a write cache already.
OR
Jump to a 6402 with a fully integrated Read-Write cache, up to 512 MB of 266MHz DDR

[Craig W]

Thanks for your advice and practical knowledge. In the meantime I was following the BBWC line, trying to get a demo part to test.

What kind of speed improvement do you think could achieved with the 128MB BBWC on the 642? I dont believe the files (total DB records) being writen are any bigger than 30MB.
Would at least an order of magnitude (x10) be achievable?

I still dont understand about the 642 slowing things down, the specs say it has 64MB RAID/read cache, 320MB/s transfer rate per channel, and the PCI-X card bus standard supports ~1GB/s max.bandwidth.
This should afford better than the recorded ~1MB/s shouldnt it?

I suppose using a std SCSI controller without any form of RAID control would improve performance, but for the tests I was using a single drive through the controllers RAID 0 settings. Shouldnt the controller just be writing through to the disk at up to 320MB/s? Am I misunderstanding what the controller is doing here?

Craig.W

[e4services]

Yes, the 642 is a 64MB read cache, 64bit RAID card and yes, it transfers data at a maximum of 320MB/sec to the drive. But the key factor in these cards is the internal processing time.
The OS tries to save the data. The data is sent to the controller. The RAID controllers monkeys around with it for 4 seconds, it seems, and then sends it down the line to the drive at the max 320 MB/s. Even if you change the RAID level from 5 to 1 to 0, it still does the same monkeying around. By adding the additional test of the Adaptec SCSI Onboard controller, you can get an idea of how much "monkeying" by the RAID is overhead.
As for the 642, adding the additional cache, it is not clear from the spec whether this adds a true write cache. The spec calls the cache a "Read Cache" and refers to the BBWC as a backup for the write. This is in contrast to the 6402 which the spec refers to as a 512 Read/Write cache.
Bottomline may be in terms of Database. You would think that in this application the entire file is open and the saving of the file is done in background. Could it not be that the P4 systems just runs the application more smooth than the Windows 2003 Server OS does? You would have to run the RAID subsystem on the P4 to really know where and what causes overhead to your write times. (Sorry I was a test Engineer at one time, so we had to write procedures all the time to try and identify things like this all the time.)

[Craig W]

Thanks again for the replies.

The 4 seconds you mentioned that the controller spends would really effect performance. I gather it would occur for each write instruction from the OS.

In this case the application is a true Database type (ISAM in this case) ie. deals in individual record reads/writes. I'm not exactly sure how the Post operation is writing to disk, however if individual records are being written one at a time, 4 seconds between each one would surely add up.

"The spec calls the cache a "Read Cache" and refers to the BBWC as a backup for the write."

I believe the backup refers to the battery in this case. Once the cache is in place I think there is full control in the ACU software over the % of Read and Write cache eg. 90% Write / 10% Read.

I'm still not sure if 128MB Write cache will speed things up here, as I monitored 900KB/s x 8.5min ~ 460MB, so if the controller doesnt pump the re-constructed disk stripes out to the SCSI disk(s) fast enough the cache will soon fill up and your back to square one.
I gather even the 512MB SCSI cache board would soon fill up if at any one time too much application data and other user/LAN data is being written to disk.

Craig.W

[Craig W]

Are there any HP Engineers monitoring this forum that could offer some technical advice on this?

[e4services]

Again, to gather more information, I do suggest your next step would be to put the DB on a SCSI drive attached to the Adaptec onboard SCSI controller with 2003 Server. Then try that setup with XP not Server. This could give you some good information

[Craig W]

Well I've completed the tests with the BBWC and the result was dramatic.

With 75% Write/25% Read Cache Ratio:

Disk Writes/s = ~3,700 (~x18 increase)
Bytes/s = ~16,000K (~x18 increase)
Disk %Time = ~50% (~50% decrease)
DB Post Time = ~.5min (~x17 decrease)

Changing the cache ratio (for tests direct on server) makes no difference to the results.

Now instead of taking 8.5min to post it takes ~30sec. I havent tested across the LAN as yet but would guess the decreased time would be similar (this will be good news to the users).

Thanks again e4 for your posts. It doesnt seem like theres a lot of time on this forum for discussions such as this but will be visiting again in the future.

Craig W

[e4services]

That is remarkable. So it is true then. Any onboard cache is Read Only and by adding the BBWC adds the ability for write cache and increases the write speeds 18 times.

Great data to share.