Sample PshopTest Results

[kaye]

PshopTest2.1
Ran it twice on 512MB file size (2183.7 res, 273.8MB Finder starting size, 512.0MB Pshop size after opened), Finder size after test completion 388.8GB.
Test1
Mac Model: G5-2.7GHz DP
Mac OSX version: 10.4.8
Video Card(s): ATI Radeon X800XT ME 256MB VRAM
Display(s): 23" Apple Cinema HD Display, 1920x1200, Millions
PCI Card(s): 2x SeriTek/1VE4 in 100MHz slots, Fw800 card in 133MHz slot
Installed RAM: 8GB
System Settings notes: Activity Monitor running: N, Internet: Y
System Volume
Hard Drive info: 279.5GB SATA Maxtor MaxLine III, 7L300S0, Spotlight Y
Volume Name: 7LMIII-16MB, Partition Number: 1 of 1
Volume Formatted Size: 279.5GB, Available Space: 144.8GB , Used Space: 134.7GB
Disk Driver Software and Version: Apple DU 10.5.6, Journaling: Y
Users/Data Volume
Same as System Volume
File Save Volume
Same as System Volume
Scratch Volume
4x150GB WD1500ADFD, Firmware 2x 00NLR0, 2x 00NLR1
1xSeriTek/1VE4, Spotlight N
Volume Name: 4xRaptor150GBRAID, Partition Number: 1 of 1
Volume Formatted Size: 558GB, Available Space: 558GB , Used Space: 0
Disk Driver Software and Version: Apple RAID DU 10.5.6, Journaling: N, 128KB stripes
Test2
Only differences from Test1 are Data Volume and File Save Volume are the RaptorRAID. Scratch Volume still the RAID Volume
Test3
Same as Test2 except file sized 1.5GB
Test4
Same as Test2 except file sized 3.0GB
Test5
Same as Test2 except file sized 6.0GB

Photoshop Version: CS2 9.0.2
Adjusted Refresh Plug-in: N, Bigger Tiles Plug-in: Y, Image Cache: 6
Photoshop Memory Settings
Available RAM: 3072MB, Max Used by Pshop: 100% = 3072MB

*Test1****Test2***Test3****Test4****Test5
512MB***512MB***1.5GB***3.0GB****6.0GB
*80s******67s*****198s****581s****1944s
Observations:
1. I added the fact that for all of the tests I used RAID 128KB stripes.
2. Keeping the System Volume out of the test mix in Test2 does make a difference, especially since it is 48% full, and even more full during the test.
3. The test runs great Boots. Very nice and thoughtful work. No complaints at all.
4. The 6.0GB file size test, 60s pauses, took somewhat longer than tested before, previous best 1859s, but I always used an 11 or 12 drive RAID. 85s more is a small price to pay for simplicity of a 4-drive RAID and more foot room.
5. For most of the 6.0GB tests, 60s pauses were more than ample, longest I saw was 40-45s of activity after the Progress window disappeared. That is until I got near the end of the tests. For instance, Convert to Profile and Convert Mode. But the 60s pause timer is smart. In Convert Mode:
Progress window closed, 67s later disk activity stopped, another 45s it went on to the next step. So 60s pauses were good for me because the start of the pause did not start when the Progress window closed.
6. My calculations for the 6GB test with 60s pauses:
Total test time 45m24s = 2724s, 13x60s pauses = 780s
2724s - 780s = 1944s
k

[Boots]

Thank you Kaye!

As you can see, test results are faster tho' test takes longer to do. But now fractional differences between first timed open step and starting a stopwatch and 'test is complete' message and stopping a stopwatch will have even less impact on 'randomizing' a final score.

But the main thing is: with the built-in 25s pauses, the scratch disk is allowed to fully write/update/optimize between steps- at least up to a 3GB file size. I believe this in turn allows the RAM-caching of scratch data to also occur in an optimal fashion so there is less memory fragmentation during the auto part of the test. The net should be more consistent scores with large amounts of installed RAM.

I tried to keep the pause value as low as possible. Originally I started with 10s but it proved to be too little with larger file sizes. 20s was on the edge with the 3GB test file size so I finally boosted it to 25s. The upside of the pauses, it does allow one to sort of walk away a bit from the computer- instead of anxiously standing by. I also think it helps to have the 'test complete' message occuring after a pause after the last save step. It gives you time to get ready to stop the timer.

[kaye]

Yes I see all that. And with the 3GB test I was able to watch the RAID's drive activity lights and did see activity stop before the start of the next step.

I was going to do the 6GB test yesterday but ran out of steam and decided to take a rest. I'm wondering, that test used to take me 31 minutes, 1859s was my best score with considerably more drives. Maybe I should set the pause for 60s and see how that goes. All I need is to see drive activity stop for several seconds to be sure the step completes, right? Or, since some of the later steps take considerably longer than earlier ones, maybe 75s? I don't know, what do you think? If I have this pause thing right, after a step completes, the timed pause starts once a step is complete but the drives/RAID will still be working to "maximizes scratch disk and memory optimization". So the pause may need to be much greater with a 4-drive RAID and my G5 DP as opposed to your Quad. Also tho I have 8GB RAM, it is much slower than yours. So many considerations. k

[Boots]

Maybe I should set the pause for 60s and see how that goes. All I need is to see drive activity stop for several seconds to be sure the step completes, right? Or, since some of the later steps take considerably longer than earlier ones, maybe 75s?

With the 6GB test file, ya- to be on the safe side, probably 60s.

I don't know, what do you think? If I have this pause thing right, after a step completes, the timed pause starts once a step is complete but the drives/RAID will still be working to "maximizes scratch disk and memory optimization". So the pause may need to be much greater with a 4-drive RAID and my G5 DP as opposed to your Quad. Also tho I have 8GB RAM, it is much slower than yours. So many considerations. k

Yes, the pause starts after the actual operation completes; the scratch disk then has a chance to do its thing completely. You've probably noticed- after most of the scratch disk drive activity occurs, then there's a little pause, then a bit more drive activity. That little bit of more activity is PSCS2 cleaning up and optimizing the scratch disk data- which I think also includes the part where it updates the scratch data held in RAM.

If you want to check this out with Activity Monitor, there should a good 5s between when all drive activity ceases and the beginning of a next step- at least on several steps. I think the routine needs a least a few steps where the scratch optimization can 'catch up' so to speak, in order for full 'optimization' to occur. It may not have to occur on every step, but I could be wrong. I'm hoping 25s is a good figure for most testers whom I'm guessing are likely to stay under the 1.5GB test file size, but your question has prompted me to wonder whether I should provide 2 choices- say 30s (all G5s & Mac Pro) and 60s (all G4s and less), depending on computer...

On a G5 Quad, 10s is more than enough for the 512MB size.

[kaye]

My previous test thread has been updated to include RAID stripe size, Test5, a 6.0GB test, and more comments about that test. Saw as high as 330MB/s disk activity in Activity Monitor. k

[Boots]

Thanks for the observations and updated results Kaye. Sounds like 60s is good for 6GB test file, and 25 or 30s good for all others. I may include something on this in an updated version..

[Boots]

Installed the CS3 beta.

PshopTest2.1 appears to run fine without any apparent need for revising. (he says while keeping fingers crossed!)

My first few tests with it:

G5 Quad 2.5GHz, 16GB RAM, Mac OS 10.4.8
PS CS3b set to default prefs except 100% RAM = 3072MB, cache level 6 (default)

1. 512MB test file, 2 x 150G Raptor SATA drives as a single 279GB volume (227GB available) stripe as startup system, users, file open & save, and scratch:

58s

2. 512MB test file, 2 x 150G Raptors SATA drives as a single 279GB volume (227GB available) stripe as startup system, users, and file open & save. Scratch on 4 x Atlas 15k II SCSI drives as a single otherwise empty 136.5GB volume stripe:

57s

3. 512MB test file, 2 x 150G Raptors SATA drives as a single 279GB volume (227GB available) stripe as startup and users. File open & save and scratch on 4 x Atlas 15k II SCSI drives as a single otherwise empty 136.5GB volume stripe:

57s

-----

So from first appearances (for PPC only), slightly faster than CS2 when using startup as scratch, but about the same or a tad slower when using external stripe as scratch or work disk/scratch disk.

It'll be interesting to compare results using larger test files.

There is no Bigger Tiles plugin. When I attempted to use a copy of CS2's Bigger Tiles plugin, CS3b said it could not load it and it wasn't compatible during startup of the app.

There is an implication from the scratch disk prefs in CS3b, that internal drives are preferable to external. Also notice the listing of the graphics card; apparently Adobe was planning on Photoshop using the graphics card for computing in some way but it didn't pan out yet for this beta (according to info on the CS3 forum):

[Boots]

Using PshopTest2.1, I did some comparison speed testing between Photoshop CS2 (9.0.2) and the CS3 beta.

The test machine is a G5 Quad with 16 GB of RAM running Mac OS X 10.4.8. All files including the scratch file (except where noted), are on two matching 150GB Raptor internal hard drives striped together in RAID0 as a single 279GB volume with 227GB of available capacity.

On certain test runs, an external SCSI array was used as Photoshop's first scratch disk. The array consists of four 36GB Maxtor Atlas 15K II drives striped together as a single empty 136GB RAID0 volume used only for Photoshop's scratch file.

During the tests no other applications were running- but except where noted Activity Monitor was pre-loaded as a startup item. CS2 had the Bigger Tiles plugin installed and enabled, but not the DisableVMbuffering plugin.

Versions of these plugins for CS3 were not included with the download. In CS3, a copy of the CS2 version of the Bigger Tiles plugin would not load, returning an error message: "Could not load the Bigger Tiles module because it does not work with this version of Photoshop."

Except where the scratch disk and memory settings were altered, the tests used the default installation Photoshop preferences.

Memory settings for both CS2 and CS3 were exactly the same; when set to 70% this translated to 2150MB. When set to 100%, this became 3072MB.

The test results (lower scores are better):

Photoshop CS2 and the 512MB test file
Test #1: scratch on startup, memory at 70%: 59s
Test #2: scratch on RAID array, memory at 70%: 53s

Photoshop CS3 beta and the 512MB test file
Test #3: scratch on startup, memory at 70%: 54s
Test #4: scratch on RAID array, memory at 70%: 52s

Photoshop CS2 and the 1.5GB test file
Test #5: scratch on startup, memory at 100%: 180s (3 min.)
Test #6: scratch on RAID array, memory at 100%: 167s (2 min. 47 sec.)
Test #7: scratch on startup, memory at 70%, Activity Monitor running: 223s (3 min. 43 sec.)

Photoshop CS3 beta and the 1.5GB test file
Test #8: scratch on startup, memory at 100%: 785s (13 min. 5 sec.)
Test #9: scratch on RAID array, memory at 100%: 756s (12 min. 36 sec.)
Test #10: scratch on startup, memory at 70%, Activity Monitor running: 1504s (25 min. 4 sec.)

-----

During the 1.5GB tests where Activity Monitor was also running, I observed memory usage closely. CS2 (and the OS) used every bit of the 16GB of installed RAM- even paging a bit towards the end of the test.

In marked contrast, CS3 and the OS never used more than 4.5GB of RAM; scratch disk activity was pretty well constant.

Comparing these results, I would hazard to guess the buffering of scratch data in RAM is not yet implemented in CS3.

[Boots]

According to Adobe, a Bigger Tiles plugin was not available at the time of the release of the CS3 public beta, and the VM buffering is not yet enabled.

I'm looking forward to eventually posting CS3 results where a Bigger Tiles plugin is installed and the caching of scratch disk data in RAM is enabled (VM Buffering).

My tests with the CS3 beta and the 512MB test file show it is already measurably faster on PPC, even without those two speed enhancements.

I am also finding that because of the Mac OSX virtual memory 'pause' bug, I need to run PshopTest2.1 2-4 x in each test configuration- both for CS2 and CS3 beta- to obtain the fastest possible results. This was not the case with CS or 7 where results could be reliably kept to within 1 or 2 seconds over a series of repeated tests with the same test configuration.

Individual test results can vary by as much as 5-10 seconds otherwise- despite using a scrupulous and exacting test preocedure where every little variable is kept the same ie., no internet, no auto scripts, no indexing, the exact same background processes and disk space between tests, waiting a full minute after desktop is loaded after restart, a full minute before Photoshop is started, a full minute before starting auto portion of test etc.

[Boots]

My new best results with the 512MB test file. PS7 and CS were each tested twice, results exactly the same; CS2 was tested 15x with results varying up to 5 seconds but pretty consistently 54s, 55s):

Photoshop 7.01, 4GB installed RAM, 2x150G Raptor stripe as startup (279.2GB, 245.2GB available, 34.1GB used) with scratch and test file on startup, 70% memory allocation (1819MB available 1273MB used by Photoshop): 77s

Photoshop CS, 4GB installed RAM, 2x150G Raptor stripe as startup with scratch and test file on startup, 70% memory allocation (1819MB available 1273MB used by Photoshop): 54s

Photoshop CS2, 4GB installed RAM, 2x150G Raptor stripe as startup with scratch and test file on startup, 70% memory allocation (3072MB available 2150MB used by Photoshop), with BiggerTiles enabled: 54s

Then I re-installed all 16GB RAM, testing 7 and CS 3x each;results were exactly the same. I tested CS2 once more with the result below.

Photoshop 7.01, 16GB installed RAM, 2x150G Raptor stripe as startup with scratch and test file on startup, 70% memory allocation (1533MB available 1073MB used by Photoshop): 90s

Photoshop CS, 16GB installed RAM, 2x150G Raptor stripe as startup with scratch and test file on startup, 70% memory allocation (1533MB available 1073MB used by Photoshop): 65s

Photoshop CS2, 16GB installed RAM, 2x150G Raptor stripe as startup with scratch and test file on startup, 70% memory allocation (3072MB available 2150MB used by Photoshop), with BiggerTiles enabled: 53s

--------

Notice the huge difference in the amount of memory PS7 and PS CS sees when 16GB RAM is installed. This was also the case when I tested 4 or 8GB in my earlier G5 Dual 2GHz machine.

And the surprise for me too is how fast CS is relative to CS2- before this I had believed the speed difference between each of these 3 versions was roughly the same ie. CS was 20% faster than 7, CS2 was 20% faster than CS and so forth.
Instead my tests are showing CS to be just as fast as CS2 with smaller files. It's only when you get to larger amounts of installed RAM and bigger files that CS2 leaves CS in the dust.

Also- these results, and a bunch of others with CS3b- definitely confirm for me that a 70% memory allocation is much better when working with smaller files. I still think a 100% allocation is an option when working with large files. You get a faster overall result but file saves suffer because the OS is being starved, and other specialized plugins may suffer also.

In my literature I will likely back off my "100% allocation with 4 or more GB RAM installed" recommendation and instead recommend 70% with the 100% option as a specialized tactical strategy for big files under some circumstances...

[kaye]

Pshop Test 2.1, Cache Levels 6, G5, 10.4.8, SoftRAID 3.6, 128KB SU. Photoshop CS2 v9.0.2.

512MB file, Memory 70% 2150MB, 30sec interval, 6xRaptor150, 64sec
512MB file, Memory 100% 3072MB, 30sec interval, 6xRaptor150, 68sec
512MB file, Memory 70% 2150MB, 30sec interval, 4xAtlas15K2, 65sec
512MB file, Memory 100% 3072MB, 30sec interval, 4xAtlas15K2, 67sec
Previous 2.1 test with 4xRaptor150, 67sec
------------
1.5GB file, Memory 70% 2150MB, 30sec interval, 6xRaptor150, 235sec
1.5GB file, Memory 100% 3072MB, 30sec interval, 6xRaptor150, 196sec
1.5GB file, Memory 100% 3072MB, 30sec interval, 4xAtlas15K2, 201sec
Previous 2.1 test with 4xRaptor150, 198sec
------------
3.0GB file, Memory 100% 3072MB, 60sec interval, 6xRaptor150, 568sec
3.0GB file, Memory 100% 3072MB, 60sec interval, 4xAtlas15K2, 582sec
3.0GB file, Memory 100% 3072MB, 60sec interval, both for 10 drives, 564sec
Previous 2.1 test with 4xRaptor150, 581sec
------------
6.0GB file, Memory 100% 3072MB, 60sec interval, 6xRaptor150, 1836sec
6.0GB file, Memory 100% 3072MB, 60sec interval, 4xAtlas15K2, 1917sec
6.0GB file, Memory 100% 3072MB, 60sec interval, both for 10 drives, 1780sec
Previous 2.1 test with 4xRaptor150, 1944sec
------------
Some Observations:
1. The 30sec intervals for 512MB file tests, I could have used less, but easier for me to calculate for subtracting the 13 intervals from the stopwatch total to yield the test result.
2. For my G5 and RAID the 1.5GB file tests, 30sec interval for some of the later steps comes pretty close to the 30sec limit. You want all drive operations completed, including cleanup and whatever else is going on which does not happen immediately after a particular step completes. Pshop does some background stuff.
3. For me with 8GB RAM, the 512MB file size, the results time difference between Memory 70% and 100% is not significant enough for me to reset Prefs to 70%. And the 1.5GB file test, 70% is much slower anyway.
4. 1.5GB file size, 4xRaptor150 is only 2sec more than 6xRaptor150. If that is the limit of your PS work, then 2 more Raptor150 drives is a waste.
5. The same can be said for the 3.0GB file size, less than 20sec time difference. I will say that even tho the stopwatch doesn't lie, 6xRaptor150 does feel during the test as if there is more breathing room.
6. If 6.0GB file file size (largest scratch file size at the end of the test is 71GB) is your typical, with Cache Levels 6, PS does benefit from as many large and fast drives as you can afford. k

[Boots]

Nice results Kaye.

I would think if you could stripe two of the 150G Raptors as an internal startup disk with testfile open/save, then 4 x 150G Raptors striped as external scratch disk- you could get the 512MB test down to 60s and the 1.5G test into the 180's.

For your rig, I would set the 1.5G test interval to 45s to maximize the fastest score potential.

Your results pretty much jive with my feeling that a 4-drive scratch-dedicated stripe is about the best cost/benefit ratio- maybe 6 drives if one is constantly working files that grow to over 2G...

[kaye]

Thanks Boots, I'm in the process of doing that, tho I am using one of my external 2-bay cases with 2xRap150 drives, the 2 with the oldest drive firmware (the other 4 for the Pshop scratch RAID are all the same later firmware). Will be Apple RAID 64K blocks. Was torn between default 32K and 64K. What do you use for block size? k

[Boots]

32k on the system....

....also- did some tests recently with different block sizes for a dedicated RAID stripe (SoftRAID 3.6); turned out 32k was slightly faster than 64k or 128k despite convential wisdom of 128k being the appropriate setting to use for Photoshop....

[TZ]

Boots,

that is what I have been reading (and being told!) lately. Makes me think there have been changes under the hood.

Will want to see new QB4 test results. From what I read, Barefeats only mentioned using it for small file sizes, not whether 10-100MB file tests will change or not.

[Boots]

I remember testing with a very early beta precursor of PshopTest (it wasn't even called that yet and the test routine was substantially different) and SoftRAID 3.0.3 back in September 2004. This test used a G5 Dual 2GHz (Original), Photoshop 7, and 879.9MB test file. Below is the chart of results I made at the time- and you can see why I concluded 128k was the fastest...

But looking back, I really don't fully trust my test results from that era because a) we discovered later the Photoshop timer didn't reflect the total time involved in an operation, and b) my testing procedure and routine was not nearly as refined as it is today.

But nevertheless, it is interesting to consider these results.

The newer tests I refered to in the post above this one used PshopTest2.1 and Photoshop CS (v8):

I wanted to test the conventional wisdom of using a larger stripe block size on a RAID0 array of multiple drives used only for Photoshop's scratch disk. I tested with Photoshop CS because of it's exact repeatability in test scores- the (Tiger) OSX vm buffering pause bug seems to have very little effect on PshopTest2.1 scores using Photoshop 7 or CS- obviously CS2 and CS3 are a different story.

I also used a large test file size to constantly work the scratch disk.

Same test bed as above: G5 Quad 2.5Ghz, 16GB RAM (8 x 2GB matched modules), nVidia 7800GTX 512MB GPU, 2 x 150GB WD Raptors striped as a single 279.2GB Mac OS 10.4.8 startup volume with 35.2GB used and 244.1GB available.

1.5GB testfile, 70% memory (1532-34MB available,1072- 1074MB used by Photoshop, cache 4, History states 20, scratch on 4 x Atlas 15K II RAID0 as a single 136.5GB volume with 47MB used and 136.4GB available. The volume was formatted with SoftRAID 3.6 as Mac OS Extended, non-journaled. Spotlight indexing was disabled on the volume. 2 tests were run for each configuration:

32k block size: 485s, 485s
64k block size: 486s, 486s
128k block size: 486s, 486s

[Boots]

Kaye, if you are inclined, it'd be real interesting if you could test the different block sizes on the striped scratch disk. I don't really know whether to take my newest results as a definitive indication that the block size makes very little difference, with 32k being slightly faster or maybe because I'm testing SCSI drives- that makes it somehow different.

I remember in OS9, changing the mode pages on my SCSI drives using FWB Hard Disk Tools (?) and how that seemed to speed up Photoshop scratch, and there were even notes in the user's guide to that effect. Course, I didn't have any standard test to really see if it had an effect.

---

I sure think it would be good for me to own a PC- eee-ghadz- where I could turn the 3GB SATA II switch on for my E7K500 drives and futz with the mode pages of my SCSI drives and otherwise have access to the deep-level drive stuff that we Mac users are sorely lacking....

[kaye]

Pshop Test 2.1, Cache Levels 6, G5, 10.4.9, boot volume 2xRap150 Apple RAID 32KB blocks or 64KB blocks, did not make even 1sec difference, PS scratch/file 4xRap150, SoftRAID 3.6, 128KB SU. Photoshop CS2 v9.0.2.

512MB file, Memory 70% 2150MB, 30sec interval, 4xRaptor150, 64sec
512MB file, Memory 100% 3072MB, 30sec interval, 4xRaptor150, 67sec
Previous 2.1 test with primary boot volumne and 6xRaptor150, 64sec
------------
1.5GB file, Memory 100% 3072MB, 45sec interval, 4xRaptor150, 198sec
Previous 2.1 test with primary boot volumne and 6xRaptor150, 196sec
------------
3.0GB file, Memory 100% 3072MB, 60sec interval, 4xRaptor150, 576sec
Previous 2.1 test with primary boot volumne and 6xRaptor150, 568sec
------------
No point in running the 6.0GB file test.
------------
Observations:
1. Seems as if this DP is at its max, however I configure it. Whatever gained by a faster boot drive (and this 2xRap150 RAID is about 2.5 times faster than my normal boot drive) is lost by the 2 less drives of the PS scratch. Appears that my horsepower is limiting. BTW, after cloning to the 2xRap150 RAID with SuperDuper, I trashed more than half of it and then used iDefrag to eliminate all the holes, one of them 60GB for X-Plane, pretty much clean and mean. Capacity 279GB, Used 73GB, 26%. Cloned to a FW RAID so that I could switch from 32KB to 64KB blocks with the 2xRap150 Apple RAID. Exercise in futility.

Nuts, I see you wanted the various sizes on the scratch disk. Maybe Saturday, got to be here the whole day since Da Boss is driving back from Thousand Oaks and I like to be here in case she has any trouble. k

[Boots]

Well thank you Kaye- that's a lot of work..

Funny, I thought you might have been able to pick up some speed with that striped startup. Makes me think I should retest my setup to verify...

[kaye]

Pshop Test 2.1, Cache Levels 6, G5, 10.4.9, boot volume 2xRap150 Apple RAID 64KB blocks, PS scratch/file 4xRap150 or 4x15K2, SoftRAID 3.6, 32KB, 64KB, or 128KB SU. Photoshop CS2 v9.0.2.

512MB file, Memory 70% 2150MB, 30sec, 4xRaptor150, 32KB SU, 64sec
512MB file, Memory 70% 2150MB, 30sec, 4xRaptor150, 64KB SU, 64sec
512MB file, Memory 70% 2150MB, 30sec, 4xRaptor150, 128KB SU 64sec
512MB file, Memory 70% 2150MB, 30sec, 4xAtlas15K2, 32KB SU, 64sec
512MB file, Memory 70% 2150MB, 30sec, 4xAtlas15K2, 64KB SU, 64sec
512MB file, Memory 70% 2150MB, 30sec, 4xAtlas15K2, 128KB SU 65sec
------------
1.5GB file, Memory 100% 3072MB, 45sec, 4xRaptor150, 32KB SU, 197sec
1.5GB file, Memory 100% 3072MB, 45sec, 4xRaptor150, 64KB SU, 197sec
1.5GB file, Memory 100% 3072MB, 45sec, 4xRaptor150, 128KB SU 198sec
1.5GB file, Memory 100% 3072MB, 45sec, 4xAtlas15K2, 32KB SU, 202sec
1.5GB file, Memory 100% 3072MB, 45sec, 4xAtlas15K2, 64KB SU, 201sec
1.5GB file, Memory 100% 3072MB, 45sec, 4xAtlas15K2, 128KB SU 201sec
------------
3.0GB file, Memory 100% 3072MB, 60sec, 4xRaptor150, 32KB SU, 577sec
3.0GB file, Memory 100% 3072MB, 60sec, 4xRaptor150, 64KB SU, 577sec
3.0GB file, Memory 100% 3072MB, 60sec, 4xRaptor150, 128KB SU 576sec
3.0GB file, Memory 100% 3072MB, 60sec, 4xAtlas15K2, 32KB SU, 588sec
3.0GB file, Memory 100% 3072MB, 60sec, 4xAtlas15K2, 64KB SU, 583sec
3.0GB file, Memory 100% 3072MB, 60sec, 4xAtlas15K2, 128KB SU 582sec

Disappointing that I can't get any kind of speed bump. Consistency achieved within each file size by defraging with iDefrag after installing the file on the scratch RAID then rebooting to run the test. The boot RAID does not seem to help me. k