The system is a 2.6 GHz quad-core i7 with 12 GB RAM and a 32GB SSD primary scratch, 200 GB of secondary scratch, with a 1 GB Radeon HD 4870, running CS4 64bit on Vista 64.
What seems odd to me is that memory usage climbs steeply for the first perhaps 4 GB, looking like the load might complete in a minute or two, then the CPU kicks in for the long, long remainder of the load. The file on disk is roughly 5 GB.
We've got issues aside from this, but I'll detail them in another thread.
Any ideas on how to improve load performance here? Thanks.
Did you configure a separate physical HDD as a scratch disc for Photoshop?
You are not creating a large poster at 600 ppi, are you? You wouldn't be the first to go down that road, only to return a few days later having found out it's a dead end. :-)
Rob
The second scratch disk is a separate physical 500 GB regular spinning disc drive with 200 GB free, and it sees no other activity aside from Photoshop use.
When the file loads, even before the primary scratch fills up, the CPU kicks in and the process lags hard. Does anyone know why?
You could say we're working on something like a high-resolution poster. It's more like we're working on a museum gallery print. I'm not the artist, but if I understand correctly, 200 ppi might be enough.
He's already done 3.5' x 6' prints. What's "dead end" about high-resolution large-scale printing?
Does it have to be 16bit? - I produce very large fine art prints ( current one is 10m x 2.5m@300ppi 8bit and load times are around 1.30mins (with 3 layers) with 16gb ddr2(800mhz)) and they've always been 8bit.
How long does it take to load?
More ram may be needed if you need multi-layered 16bit images.
What's this weird stuff going on during load? Is Photoshop somehow deciding to do an unreasonable amount of tiny writes to scratch?
About the 16 bit / channel -- the artist does not seem to want to budge here. I explained the concept of human eye sensitivity versus the 24 M colors available from 8 bit, but he has a few reasons he's resistant. The first is he wants to maximize fidelity (color range, resolution) throughout as much of the process as possible before collapsing to the range available at the print shop. The Hasselblad provides data at 50 megapixel and 16 bit and he wants to carry those as far as he can.
If he can solve the problem with throwing more hardware at it, he'd rather do that than chance losing fidelity earlier in the process.
Rather than attempt the tack of persuading the artist to collapse fidelity earlier, I would prefer to focus on what is going on technically. It's not clear to me that throwing hardware at the problem will expand the degree we can carry the fidelity. I don't know how to fit more than 12 GB RAM into a system.
My primary concern at this point is figuring out just how the system is constraining the work. What's generating the lag?
Relatedly, how is one supposed to do a large resolution image in Photoshop?
So except for our being in 16 bit your images are far larger? Our objective is to-scale prints of our subject matter. Right now we've captured images that represent 2 x 3 meters printed with good resolution. We're aiming ultimately to capture images at the size you appear to be working at.
What kind of hardware are you using?
Could the problem be that Photoshop does a poor job of handling 16 bit images?
A 64 bit OS and more RAM might help you.
With 12 GB of RAM and a 32 GB fast dedicated scratch disk I'd expect to be able to handle large images pretty well. Is this setup really not adequate for a 10000x20000 pixel image? If not, what specs would you say are adequate for work in this realm?
Is a 20 minute load time to be expected even when one is hitting scratch during load?
Also remember that the size on disk is compressed - in memory it will be larger. With the right layer contents, it could easily exceed the 32 Gig primary scratch size. When you have the document open, look at the document size that Photoshop reports and see how large it is in memory. (I'm betting it's over 30 Gig)
How to improve load performance: work on a smaller file, allocate a larger percentage of RAM to Photoshop, get more RAM, get a faster scratch disk (including a RAID array).
I'm using a q6950@3ghz, Asus p5q deluxe m/b, 16gb ram, 1 system drive (74gb raptor), 1 file drive (7200rpm), 1 dedicated scratch disk (150gb raptor), 1 dedicated large format image drive for recent projects (750gb 7200rpm).
I try to keep most file writing/reading elements on separate drive so that the disk heads are not conflicting or fighting for access.
I hope this helps
chris
Rob
Yes, if you're waiting on the scratch disk - then that load time sounds
about right.
The scratch disk is rated at 227 MB/s for write speed. Does Photoshop have a problem with SSD scratch disks?
I mean, in 20 minutes' time I should be able to write 266 GB. And by the time the file finishes loading, the full 32 GB aren't used up, so nowhere near the drive's max speed is being achieved. This is the Intel X25-E -- I think it's the gold standard right now as far as SSD performance. Maybe Photoshop is writing scratch using really small chunk sizes?
Has anyone used Photoshop with the X25-E?
That's 227 if you had a simple, single stream going -- and scratch disk access isn't that simple.
Using the Large Tiles plugin might help your performance - give it a try.
Copied this from the windows help site. According to what is indexed: pictures are one of them.
I'll do a test when I get to my office and see how long a similar file takes to load on my Vista64 system.
I once saw a technique demonstrated where an image was converted to a Smart Object, its size was changed (ie: from 10000x20000px to 2000x4000px). Retouching was done on these smaller versions. Then as a final step the size was reset to it's original pixel dimensions and magically the image was rendered back to the larger size without any quality lost. That seemed a bit far fetched though the idea of working with smaller 'proxi' images has been around for a while (Macromedia xRes) and I've been meaning to try it on huge images like hirez collages. Anyone know what's up with this?
12000 x 18000 px, 16 bit, 5 adjustment layers plus one normal layer. This seems awfully fast compared to your numbers - did I miss something?
This is a fairly modest system by current standards: Vista64, 8GB, C2D E6750, separate scratch (7k2) but no RAID. CPU usage around 35-45 % per core throughout. Total RAM usage reported by Task Manager 6,53 GB.
Maximize compatibility off, Vista indexing off.
12000 x 18000 px, 16 bit, 5 adjustment layers plus one normal layer.
No, it's 6 different images (all 16bit) on 6 layers PLUS the adjustment layers totalling 12.
Specs are: "10000x20000 pixel 16 bit image with maybe 6 image layers and 12 total layers."
Opening a 'one layer image' with a few adjustment layers takes me only 15 seconds to load after a cold boot. Opening the image right after saving it is a bit of a cheat as much of it will load from cache.
It was just an image that I happened to be working on, upsampled.
I couldn't get him to test the SSD performance, or to tell me if the bog down seemed to correspond with the time the system overran RAM and went to scratch. Anyway, if he has the money, the RAID of SSDs is not a bad thing to have. It's 4x the space, too, which is nice, and it's expandable (both performance- and space-wise), which is nice.
Lawrence: It seems everyone is recommending taking manufacturer speed ratings with a grain of salt. Thankfully there are a number of third party benchmarking reviews. Did your filter operation even touch scratch?
Chris Farrell: The idea is to create a composite, so having all the images in a single file seems critical. The later we can put off merging layers, the better off the artist is in being able to do his work. I'm hoping that ultimately we can avoid doing any merging that's inconvenient for him, but we'll see what necessity dictates. Thanks very much for sharing your setup info. It gives me hope.
Our current image relative to yours is about 1/10 the pixels, 2x the color depth, 3x the image layers. A simple (simplistic, probably) calculation says that your working file size (in-memory size) might be 1.6x what we should be getting. I have not been able to get the artist to report the working size. Is this the value reported in the PS4 status bar, or is there another place I should ask him to look? (I think the 20 minute load time depresses him, so if I can ask him very succinctly, the effort stands a better chance of happening.)
Chris Cox: I expected that Photoshop doesn't do simple streaming write for scratch, but the exact nature of its scratch interaction would really help me to provision a device to handle it. If you have any idea of what kind of operations Photoshop does with scratch, that would be really helpful. Specifically, the size and frequency of reads and writes. I imagine comparing the information to a graph like this:
<http://metku.net/reviews/patriot-warp-v2/atto.png>
Freeagent, Russell: Thanks very much for your testing. The information makes me hopeful that the problem really is about scratch space usage and not something weird like Vista swapping Photoshop without Photoshop's knowledge.
If it is scratch performance, there's the possibility that Vista has difficulty with SSDs. There seems to be a lot of discussion out there about tuning Vista to work with SSDs. I'm hoping that the RAID might insulate Vista from the SSDs enough that no tuning will be needed, but I'm reading up on tuning anyway (and trying to disentangle what's relevant for a dedicated scratch drive as opposed to an OS-containing SSD).
There's a point where optimizing one process further will not increase overall efficiency much further as the cause of any slowdown probably lays elsewhere.
Always have a backup!
Bob
David: RAID 0 is faster than what?
Russell: It's hard to tell where the system is currently being constrained. I'm hoping that if the RAID of SSDs doesn't solve the speed issue that the artist will give me some time to diagnose.
SSD's are rather at the primitive state. Potentially, there is great promise for speed increase, but SSD's at best will not match the number of read/write cycles that magnetic materials can do. It also depends on whether the unit is a single level cell (SLC) or multi level cell (MLC). MLC is slower and less reliable but cheaper, as more data per cell is available.
Google SSD and you will find a plethora of information
The unit I checked costs about $800.
No, it's not...it's a theory. I have two machines here with RAID(0). One
is a bit over a year old, the other about three and half years old.
Neither has been a problem.
Over that time, I've read countless stories of crashed harddrives in non
RAID setups. I stand by statement. Go for the increase in performance
and have a good backup because it doesn't really matter what happens
when one drive containing valuable data crashes if you don't have it
backed up.
Bob
It's hard to tell where the system is currently being constrained. I'm
hoping that if the RAID of SSDs doesn't solve the speed issue that the
artist will give me some time to diagnose.
My point was that you will at some point hit the maximum performance that current desktop computers offer, and until there are improvements in all parts of the chain, there's nothing much you can do to make it go any faster. I suspect you're wasting a lot of effort to get a very small % change over what you've experienced to date. I'll be watching the thread to see what you've come up with. I hope your friend will be able to accept that at one point it's as good as it's going to get.
As Scotty was fond of saying "Ya can't change the laws of physics!"
:-)
<http://en.wikipedia.org/wiki/Raid_0#RAID_0_failure_rate>
I appreciate that your personal experience may compellingly conflict with this idea.
(An important footnote: A RAID 0 of SSDs has a different Mean Time Between Failure calculation than a RAID 0 of spinning disks. Spinning disks degrade continuously during power-on time, while the disks spin, but SSDs degrade with use. So since a RAID 0 array divides use across drives it actually _improves_ the longevity of groups of SSDs. Anyway, _that_ is a theory.)
Lawrence: The SSD certainly did what? I think maybe you're saying that the Photoshop operation you performed certainly made use of scratch. Did you verify this by some means, such as watching the scratch file grow?
For general performance, some SSDs have been measured to do very well. See the results in this article:
<http://techreport.com/articles.x/15931/2>
The Intel X25-E SSD leads a pack of 7200 and 10K RPM drives.
The question remains of whether Photoshop's scratch access profile aggravates specific shortcomings of SSDs (small chunk problems). And whether there's anything that can be done about that.
As for endurance, "million cycle flash" has been around for almost a decade and is now commonplace. This means, as far as rewrite cycles, modern SSDs have a continuous-use lifetime of half a century.
<http://www.storagesearch.com/ssdmyths-endurance.html>
(Though there is some question about degraded performance over time, caused by shuffling around blocks and there's some talk about "refreshing" drives using a kind of low-level erase.
<http://www.pcper.com/article.php?aid=669>
)
In reality,the chances are so slim that 1 ticket has just as much a
chance as 5.
Same for RAID(0). Again...what's the difference if you have one drive
with data on it crash on you or one drive in a RAID crash?
The answer is zero and the benefits of RAID(0) with large files is well
worth it.
Bob
As I said, the expectation of better performance is there, and is valid.
I ran my tests late last year. Probably outdated/ But still, even $400 is too much for a scratch disk, imo.
The low level erase is using the same technology as re-write cd's. That holds the greatest promise, because (MLC) flash has to erase to 0's before re-writing, which means that the data has to be copied then written back.
So far as statistics, well, one event doesn't make or break the numbers.
You mean your real life, right Bob?
Raymond: Last year I was just reading up on RAID for Photoshop and 3d max runnig faster. But as Bob pointed out, and I agree with him, that a back up hard drive is much better. Safer anyways. I just use 2 300 gig velociraptors as separate drives.
As mentioned above there is a lot more involved like other hardware and motherboard and such.
because it doesn't really matter what happens when one drive containing
valuable data crashes if you don't have it
backed up.
not really. if you lose a drive out of a raid array you have slim to no chance of recovering it. if a single drive crashes, chances are fair to very good you can get back most or all of what was on the drive at some point, depending on your determination (or what's in your wallet).
1. From earlier: The nature of Photoshop's scratch activity would really help me to provision a device to handle it. If you have any idea of what kind of operations Photoshop does with scratch, that would be really helpful. Specifically, the size and frequency of reads and writes. I imagine comparing the information to a graph like this:
<http://metku.net/reviews/patriot-warp-v2/atto.png>
2. Is there an optimal NTFS cluster size for scratch? Is there an optimal RAID 0 stripe size for scratch?
3. Could Windows be swapping out Photoshop unnecessarily (i.e., causing slowdown)? Might turning off the pagefile help performance?
4. Are you familiar with SteadyState? Are you aware of that helping Photoshop performance with spinning disks or SSDs?
5. Is there any way to disable PSD/PSB compression?
6. What is "DisableScratchCompress", and do you think it might help? And what about "ForceVMBuffering"?
Meanwhile, I'll give a try at the "Bigger Tiles" plugin you suggested. Thanks very much for that.
Bob
2) Not that we've been able to determine. The performance has more to do with the RAID controller once you have 3 or 4 fast disks. (2 disks helps, but they're still the bottleneck)
3) No, turning off the pagefile is always a mistake.
4) Not really, but it doesn't sound like it would help anything...
5) No.
6) Try them. They may or may not help depending on the characteristics of your system. (That's why they're optional)
4. Here's where the idea came from: <http://www.pcper.com/article.php?aid=669&type=expert&pid=7> :
SteadyState reroutes all disk writes, regardless of their randomness,
to a contiguous ‘change’ file. This brings small write performance much
closer to the ‘sequential write’ speed of a given drive. In the case of
the X25-M, it will significantly reduce the internal fragmentation that
occurs as a result of random writes.
5. :( Any plans for uncompressed PSDs? Or maybe multi-threaded file loading?
6. I'll give them a try.
Thanks very much for your answers, Chris.
Thanks very much for your answers, Chris.
as always. thanks chris!
4) Hmm, interesting side effect - but likely to cause problems with a scratch file and heavy IO.
5) Nope. Threading won't help a single file load - the best threading could do is load in the background while you work on another document (slowing both down quite a bit). And we have a lot of work to do before we could load or save in the background.
It'll be a few days before we have the new RAID set up, but I'll try to get some performance numbers (benchmarks of the array and of Photoshop's use of it) to share with everyone here. I might also try SteadyState to see if it has any impact.
Cheers.
A striped (0) RAID is as many times more vulnerable to failure as its
number of drives
I'm resurrecting this because it just occurred to me why that argument is meaningless. It's Schroedinger's cat.
You cannot use statistics to predict the behaviour of individual cases. It's a different paradigm.
OK, next ;-)
It's Schroedinger's cat.
I thought that one was dead. :)
It is, but the backup is running just fine. <g>
Bob
OK, OK. Different metaphor: how about the guy with one hand on the stove and the other in a bucket of ice. That's how long before your drives will fail, RAID or no RAID. There's just no telling either way.
Ultimately 5 Seagate Barracuda 7200.12s were reportedly installed by the artist (as a RAID0 presumably), but he continued to have problems. He seems uninterested in having me help to diagnose where the bottleneck exists, so I have no benchmarks to share with that setup.
My guess is that he lost confidence in my being able to help after the system failed to perform to his desired levels when it was first built. I hear he's enlisting the help of someone with nine years of Photoshop experience. I hope he can do something. If I hear any information about their progress I will share it.
Sounds like he will find out the hardway that sometimes a system just can't be tossed together, expect it to go POOF, and be perfect.