Defiler

Terrible SCSI performance in Windows XP

Recommended Posts

I did a quick Atto benchmark to test FAT32 vs NTFS and XP vs Win2K and SCSI vs ATA66

I don't have the info here (it's at home, and I'm at work), but here is the lowdown:

All tests performed on the same machine, dual booting Win2K and XP. Same drives, etc. ABIT ST6 (Intel 815EP chipset),Celeron 1A OC/d to 1.33GHz via 133 FSB. Win2K Server and XP Professional. 512MB RAM

ATA66 performed well, writes were 95% or more of the read speeds, maxing out around 17MB/sec at pretty low KB block sizes, both in XP and Win2K. No surprises here. IBM 25GB ATA66 drive.

SCSI: I confirmed the problems shown here.

Seagate Cheetah 10K (18GB ST118202LC) through an old ALR SCA backplane, driven by an Adaptec 2940UW (yeah, I know, its slow)

Read performance was great, maxing out at around 19+MB/sec on both FAT32 and NTFS (no effective difference, btw, between the two file systems).

On XP, the write performance SUCKED, and started to scale. By 64KB, it was up to where it should be, but at 1KB it was about 1/5 - 1/10 of what it should be!

On Win2K, write performance was 95-99% of read performance at all block sizes.

I'm thinking of going back to Win2K. I boot from an IBM 10Krpm 9GB SCSI drive, and want my performance back.

Share this post


Link to post
Share on other sites

I'm with you Bill. Though I like a lot of things about XP, I don't like my sub-par scsi performance. I'm not willing to endure the headaches until September for SP1.

Share this post


Link to post
Share on other sites

I just did the atto benchmark and I get the same thing. Writes get to almost 40 mb/s but the reads wont get above 11 mb/s =( At first I thought it was my scsi controller then I saw this..... Great. I can't afford to go back to 2k now though..

Share this post


Link to post
Share on other sites

Then again with such low transfer rates on small blocks one would definitely feel it (10 times lower than my D540X IDE in some case). I don't have such an impression of slowness on my own system though.

Share this post


Link to post
Share on other sites

Well, under "normal" conditions, writes are a FRACTION of reads.

I'm not sure if ATTO bypasses cache or not. XP's file system cache would help hide some of the problem.

I'm not in front of my workstation right now, so I can't test that thought with other benchmarking tools.

Share this post


Link to post
Share on other sites

I'm planning to upgrade to an Asus A7N133C with the nForce 415 beginning of the week. Right now i have a Epox 8K7A (AMD 760 with Via Southbridge) with a Tbird @ 1.53. Using X15-36LP 1 5GB part, 1 13GB part. FAT32, dont' know clusters size. WinXP Pro. Tekram SCSI 160SCSI Card.

for 1024 bunch in Atto i get 54000 write and 55000 reads.

for the 16K i get 10000 and 55000.

So my writes seem fine for now. I did so many tweaks before, i'm nost sure what i did. My drive is pretty fragmented though. I might do a few more tests if i have time. But i'll let you guys know if the nForce does anything to performance.

Share this post


Link to post
Share on other sites

For real world numbers, concentrate on the 4K and 8K results.

Also, NTFS vs FAT32 has nothing to do with this issue, and neither does fragmentation.

If you ran the same tests against an ATA drive, you'd have write performance that was nearly equal the read performance at almost ALL block sizes. At 16k, your write performance is less than 1/5th what it should be.

Share this post


Link to post
Share on other sites
Well, under "normal" conditions, writes are a FRACTION of reads. 

You should probably have a look at the graphs i provided where reads are mostly as low as writes...

Share this post


Link to post
Share on other sites

I just spent about 5 minutes replying, and this silly BBS threw it away :x

By "normal" conditions, I meant real world loads, not ATTO loads. Real world usage is most often a 90/10 or 95/5 or 80/20 between READ and WRITE. It also isn't I/O artificially generated by a benchmark tool. The exceptions include streaming data of any sort (seismic measurements, streaming media, etc.)

Your parity (equally poor) read/write performance at low block sizes is different than I and some others are reporting. In my case, low block sizes have write performace at 10% of the reads. Also in my case, ATA peformance as measured by ATTO was WAY higher for writes, essentially equal to reads and reads were much higher than you measured.

I won't spend 5 minutes replying in detail again, but essentially I need to go back to basics and do testing with other benchmarks to determine if we are getting artificially strange numbers with ATTO or not. Due to the disparity between SCSI and IDE results, I tend to think XP is at fault. Fragmentation and file system type are not the source, as I successfully tested around those variables.

BTW, I do a lot of disk benchmarking for a living, as a Systems Engineer/Field Applications Engineer for a Storage Networking startup company. I'll be happy to get details back here (including screen shots) next time. My test bed is my primary workstation, and I'm 130 miles away on my laptop currently.

Share this post


Link to post
Share on other sites

ran atto w/ tekram u2w (latest bios), both ntfs & fat32, both x15-36lp & 36lzx, both wxp & w2k, both ide & scsi, both o/s native drivers & latest tekram.

was able to reproduce problems mentioned here for all wxp + scsi drives (both drivers, both file systems).

no ide probs anywhere.

w2k looks beautiful.

looks like wxp + scsi = problem.

cusl2 (i815e), p3-933

Share this post


Link to post
Share on other sites

Waiting for a SP from Microsoft for multiple months is just unacceptable. I'm sure if microsoft knew of this problem they would put a critical update out. I mean XP is aimed at EVERY field that includes workstations. If XP doesn't work with SCSI Microsoft would loose half of their stakeholders.... So.... What I am asking is has everyone here contacted microsoft????

Share this post


Link to post
Share on other sites

I think we've been chasing a non existent problem!

I just benchmarked using IOMETER (from Intel Corp), and the write performance is great under XP.

My gut feel right now is that ATTO is deficient, not XP.

Here is where you can grab IOMETER (free download from Intel).

http://www.intel.com/design/servers/devtoo...er/download.htm

(search on www.intel.com for IOMETER and you will find this link plus links to a new open source version (source only) as well)

Grab this ICF file (benchmark profile) to help in a quick benchmark, or roll your own.

http://www.pirate4x4.com/~billp/w2k-vs-xp.icf

(save it as a file under your IOMETER installation directory)

This ICF runs 1 minute runs at each block size, with a 15 second "flush" at each block size (not measured). It also has a 1 minute flush before running all the other block (ignore the first 64KB run).

If you run against a BARE (*no file system) drive, it runs immediately. If you run against a file system drive, it fills the drive with a test file. This can be HOURS. I ran my test against a bare drive, as I did with ATTO.

I think, based on tonights test, that we can forget about this so called "XP SCSI problem".

Comments?

Share this post


Link to post
Share on other sites
I won't spend 5 minutes replying in detail again, but essentially I need to go back to basics and do testing with other benchmarks to determine if we are getting artificially strange numbers with ATTO or not.  

If you'll read the beginning of the thread again, you'll see that I've verified ATTO's results with straight file copy operations.

Copying a file from D: to X15-36LP: 12MB/sec. Copying a file from D: to 1200JB: 40MB/sec.

It's not just ATTO.

Share this post


Link to post
Share on other sites

Defiler, did you try to use Explorer rather than TC ? When i use TC things are getting much slower here while Explorer is nearly 5 times faster considering disk to disk copies.

Share this post


Link to post
Share on other sites
Defiler, did you try to use Explorer rather than TC ? When i use TC things are getting much slower here while Explorer is nearly 5 times faster considering disk to disk copies.

Yes. I also tried it with Explorer and a stopwatch.

Share this post


Link to post
Share on other sites
Yes. I also tried it with Explorer and a stopwatch.

Me, too. In my case, I didn't even have to use a stopwatch. :) Explorer copied a 500MB to X15-36LP in more than three minutes.

Leo

Share this post


Link to post
Share on other sites
I think we've been chasing a non existent problem!

I just benchmarked using IOMETER (from Intel Corp), and the write performance is great under XP.

My gut feel right now is that ATTO is deficient, not XP.

[...]

I think, based on tonights test, that we can forget about this so called "XP SCSI problem".

Comments?

Unfortunately, my own IOmeter results agree with ATTO, and so does a timed file copy test. I ran IOmeter on a partitioned drive, though. I wonder if that might have made the difference. I wouldn't be too surprised, though, if indeed the operating system is at fault.

Leo

Share this post


Link to post
Share on other sites

I'll go back and do straight file copies as well.

I'm running timed tests with IOMETER today (I kicked them off before I left the house).

At 1K blocks, I was getting 10MB/s read and write. With Atto I was getting 10MB/s read, and something like 400k write.

We could be seeing two things here... so let's all grab the same data points and repost our data.

ATTO

IOMETER with like/like ICF profile

500MB file copy

.

.(thoughts?)

The file copy becomes an issue because of fragmentation. But that shouldn't affect the order-of-magnitude difference we are seeing in I/O rates.

Also important to note is the cluster size for those of you who are using a file system. ESPECIALLY for the file copy. My understanding is that file copies under Win2K/NT/XP use the cluster size of the file system. So even if you are doing a large streaming write, you are actually doing 4K I/O. And those of you who have used 512byte clusters in order to save disk space have actually forced yourself to put up with inefficient I/O for most larger files.

That's why I prefer to benchmark raw devices instead of file systems, unless I'm comparing file systems.

Share this post


Link to post
Share on other sites
That's why I prefer to benchmark raw devices instead of file systems, unless I'm comparing file systems.

Sure, but the actual USE of the system takes place on top of a filesystem, so you have to take that into account in any real benchmark/diagnosis. We're not comparing drives here, we're trying to figure out why the write speed sucks so badly in WinXP.

Share this post


Link to post
Share on other sites
Sure, but the actual USE of the system takes place on top of a filesystem, so you have to take that into account in any real benchmark/diagnosis. We're not comparing drives here, we're trying to figure out why the write speed sucks so badly in WinXP.

Agreed, but it adds variables. If you can show differences once you've removed variables, you no longer have to ask about those variables.

Right now, if someone benchmarks an 80% full drive and gets a partial loss in performance, they don't know if it is the file system driver, the fragmentation on the file system, XP's ability to deal with fragmentatin (back to the file system driver), etc.

If one demonstrates a clear issue with a raw drive, then you have proven it is a lower layer issue.

Using raw devices also gives clearer results.

ATTO is CLEARLY doing sequential (only) writes and reads. This isn't "real world" either. But we clearly can use it to benchmark.

Luckily for our tests, write performance as measured by certain tools is SOOO BAD that you can't attribute it to a lightly fragmented system.

I'm going to try the file writes, and I'm going to go back and re-read your posts (and others) to expand the range of my tests.

All-

Years ago (NT 3.51 days) I proved to some colleagues that Explorer and a command line XCOPY use different buffering of writes. I'm not sure what differences exist today, but rest assured that there can are probably are big differences in how Explorer and a command line (maybe even COPY vs XCOPY) operate, and how they benchmark. So we must be clear on what we are measuring (XCOPY vs. Explorer copy vs. ....).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now