should a GPU , RAM and solid stateHDto speed up giga panorama process?

[HansKeesom]

by HansKeesom » Mon Aug 15, 2011 9:13 pm

Hi Kreature,

The SSD was the best thing I ever bought for my computer!

Today I did a test with my little system that has only 6 GB of RAM to see what would happen when bigger panoramas would be thrown at it.
I took a set of 744 files (NEF-RAW) which were stacked in 3 exposure layers, resolution was 6 megapixel

According for you formula this would mean 6 * 744 * 4 = 17856 MB or 17,5 GB of scratchfile.
However, my SSD had it's temp-directory filled with 49 GB and then on a harddisk another 9 GB were plced so totalling 56 GB. I find a difference of a factor 3. Could it be that using 24 bit MEF's instead of 8 bit jpg explains the difference?
If so we need to add the following to the formula "* colordepth/8 "

[KreAture]

by KreAture » Mon Aug 15, 2011 9:43 pm

First off, RAW files are converted to uncompressed TIFF's as far as I know.
That accounts for insane ammounts of space.

[HansKeesom]

by HansKeesom » Mon Aug 15, 2011 10:44 pm

Hi Kreature,

I converted them to compressed tiff first, made AGP rathers slow in detectionphase. So stopped that and used enfuseGUI to fuse the stacks. That left me with 248 files. Now your calculation did work. 6 * 248 * 4 os 5,952 GB which was only a bit over what the actual temp-files occupied.

So formula is still standing under the condition that you convert all to compressed tiff's first (and fuse stacks before using APG)

I did see my cpu% being lower then what I have with smaller pano's. Windows sourcecontrol learned me there was a lot of temp-files being read at speeds up till 84 mb/sec. That problably is telling me that if I more often want to do this kind of panorama I can win a lot by buying a much faster SSD.

regards,

Hans

Last edited by HansKeesom on Tue Aug 16, 2011 5:02 pm, edited 1 time in total.

[tived]

by tived » Wed Aug 17, 2011 3:25 am

Great work guys!

Well, i rest my case regarding system building and will just refer to the PTGui benchmark test http://hdview.at/speedtest/results.html4. :-) <evil grin> (now I just need to get better at using the software! :-) <not so evil grin>

Sure we can calculate how much scratch disk, ram, etc... but you are unlikely to add and remove hardware everytime you need to build a pano. at the end of the day you are going to need to build a system you can afford and that will fullfill your needs, at for that point the above formula is very handy, and then again next time you need to upgrade.

I think in my own case the ideal system is 3-4 arrays with 8 disks in each, not that I am likely to get a system like that due to $$$ constrains but I think that is what is required to make Giga-pano's or high detailed pano's in a reasonable quick time. Given the latest SSD disks available this would give me a transfer speed in excess of 2+ Gb/sec.

I wasn't going to comment on this but i can't resist - Ronald, your 6 disk raid is very fast there is no doubt it. But a multiple raid setup will be faster IMHO because the computer does not have to wait for it to read and write back to the same disk. Where as a multi disk set up where you move the data through the system will separate the tasks and is able to execute these simultanously AFAIK. We are probably splitting hairs here, but as a general throught the idea of multi-RAID setup should be faster.

Its really hard to compare these things but how about you run the test from the above benchmark, if you haven't done so already and let us know the result. thanks

When we later are able to use the GPU's for more then just previewing that will be greatly beneficial, however, the storage will always be the bottleneck.

Henrik

[gddxb]

by gddxb » Wed Aug 17, 2011 7:29 am

That's one fast machine you've got there Henrik. I've just run the test in 4'43. I've uploaded the details - I suspect in my case the CPU is the limiting factor.

[tived]

by tived » Wed Aug 17, 2011 8:13 am

gddxb,

what name are you going under - also I think it may take a day or so for it to show, as I think Bearnard is verifying it first

Henrik

PS: Its fast but there is room for improvements ;-)

[HansKeesom]

by HansKeesom » Wed Aug 17, 2011 8:15 am

Great work guys!

Well, i rest my case regarding system building and will just refer to the PTGui benchmark test http://hdview.at/speedtest/results.html4. :-) <evil grin> (now I just need to get better at using the software! :-) <not so evil grin>

Sure we can calculate how much scratch disk, ram, etc... but you are unlikely to add and remove hardware everytime you need to build a pano. at the end of the day you are going to need to build a system you can afford and that will fullfill your needs, at for that point the above formula is very handy, and then again next time you need to upgrade.

I think in my own case the ideal system is 3-4 arrays with 8 disks in each, not that I am likely to get a system like that due to $$$ constrains but I think that is what is required to make Giga-pano's or high detailed pano's in a reasonable quick time. Given the latest SSD disks available this would give me a transfer speed in excess of 2+ Gb/sec.

I wasn't going to comment on this but i can't resist - Ronald, your 6 disk raid is very fast there is no doubt it. But a multiple raid setup will be faster IMHO because the computer does not have to wait for it to read and write back to the same disk. Where as a multi disk set up where you move the data through the system will separate the tasks and is able to execute these simultanously AFAIK. We are probably splitting hairs here, but as a general throught the idea of multi-RAID setup should be faster.

Its really hard to compare these things but how about you run the test from the above benchmark, if you haven't done so already and let us know the result. thanks

When we later are able to use the GPU's for more then just previewing that will be greatly beneficial, however, the storage will always be the bottleneck.

Henrik

Henrik,

No-one is suggesting adding and removing everytime you need to build a pano.

The formula and the step that follow it give us a clear indication of what to expect when given a certain set of photos and a certain amount of RAM. It allows for wise spending of money. If you know what set you normally have to process you can get an idea of how much RAM would be perfect.
The steps after the formula give some advice/choices on how to improve the performance of your machine.

What you say about multi-raid etc, connects to what has been said earlier in this thread about feeding data fast enough to the processor and making sure it can write it away again. A good indicator is the average CPU %, if it is mostly below 75% it is problably not being fed fast enough. In windows source-control can show what goes on.

I downloaded the speedtestzip and have a number of comments.
- Making panoramas is not about who is the fastest on a certain panorama. I assume it is more of interest to find out what decisions one can make regarding a new system that is to be bought or a existing system that is to be upgraded. The result sheet has a lot of data in it, what analysis can be made with it?
- Testing with 100-200 kb source files seems unrealistic to me. Larger files should be used to create a realistic situation. It will likely put more pressure on disk I/O and will ask for larger temp-directories
- The frontpage says you need 60 GB of temp-disk. Using the formula of Kreature i calculate 337*6,1*4 = 8 GB. Looking at my tempdirectory (on SSD) I see autopano does not even get close to that, problably due to the small file sizes. Anyhow, 60 GB is too high. Do you agree here?
- In my case I see my CPU running at 90-95% and autopano running at 70-85 %. This indicates there is not much that can be done on my system to speed things up as my CPU is nicely busy on all 4 cores/8 threads. At the moment I am not doing panoramas of 337 photos on a daily or even weekly basis. So businesslogic dictates to me not to invest for this size of panorama. Others will choose differently


Hans

Last edited by HansKeesom on Wed Aug 17, 2011 9:02 am, edited 1 time in total.

[gddxb]

by gddxb » Wed Aug 17, 2011 8:46 am

gddxb,

what name are you going under - also I think it may take a day or so for it to show, as I think Bearnard is verifying it first

Henrik

PS: Its fast but there is room for improvements ;-)

Sorry - Gerald Donovan.

[Ronald]

by Ronald » Thu Aug 18, 2011 5:00 am

Great work guys!

Well, i rest my case regarding system building and will just refer to the PTGui benchmark test http://hdview.at/speedtest/results.html4. :-) <evil grin> (now I just need to get better at using the software! :-) <not so evil grin>

Sure we can calculate how much scratch disk, ram, etc... but you are unlikely to add and remove hardware everytime you need to build a pano. at the end of the day you are going to need to build a system you can afford and that will fullfill your needs, at for that point the above formula is very handy, and then again next time you need to upgrade.

I think in my own case the ideal system is 3-4 arrays with 8 disks in each, not that I am likely to get a system like that due to $$$ constrains but I think that is what is required to make Giga-pano's or high detailed pano's in a reasonable quick time. Given the latest SSD disks available this would give me a transfer speed in excess of 2+ Gb/sec.

I wasn't going to comment on this but i can't resist - Ronald, your 6 disk raid is very fast there is no doubt it. But a multiple raid setup will be faster IMHO because the computer does not have to wait for it to read and write back to the same disk. Where as a multi disk set up where you move the data through the system will separate the tasks and is able to execute these simultanously AFAIK. We are probably splitting hairs here, but as a general throught the idea of multi-RAID setup should be faster.

Its really hard to compare these things but how about you run the test from the above benchmark, if you haven't done so already and let us know the result. thanks

When we later are able to use the GPU's for more then just previewing that will be greatly beneficial, however, the storage will always be the bottleneck.

Henrik

tived,

I'm an empirical person, and, believe me, in some point I tried to configure my computer with two HDD SAS 15k and in RAID-0 (for the OS/APP's) and four HDD SATA 7.2K in RAID-0 (for RAW/TIFF/PSB and APP Temp folder) and the result was not even close the performance that I having right now (unfortunately my system only allows up to 6 HDD's). I could think about the reasons, but, it would be just theories!

I also noticed that many people is referring to the CPU's performance, and even when I never mentioned before, the CPU performance using the 6 HDD configuration is very good (pretty much between 92 and 100%) see the image.

I think that I cannot do too much to improve the performance in this computer, a mean, I should start thinking in something new with SSD or SAS/SATA 6G, 64GB RAM and dual XEON E7 Processor.... but, it would be just a dream... ;-)

BTW: The PTGui benchmark link doesn't work, could you check it?

[tived]

by tived » Thu Aug 18, 2011 5:16 am

Sorry Ronald

here it is http://hdview.at/speedtest/results.html

Do you have a server case? with SAS hotswap?

If you are looking for a new mainboard with dual XEON that can go a bit further then I can recommand EVGA SR-2, but I am sure in the next year or so we will see newer and better technologies as the CPU's improves.

I would be very interested to see how fast your 6xRAID-0 is

thanks very much for sharing

Henrik

[Ronald]

by Ronald » Thu Aug 18, 2011 6:10 am

tived,

I did run an initial test using APP, and the application generated an error (see image); I will report the bug...

Either way, I noticed a particular slow performance before the crash (about 5 minutes), but, then I started looking to see what was the problem, and I found a big problem (at least for me)... the images are too small for my raid configuration; a mean, the stripe (element size) value, in my configuration is 1024kb (not 64kb), so, a file smaller than 7MB would generate a bottleneck in my computer.

I did the configuration in that way, because, I only use TIFF16 images as source in my panoramas which usually are about 60MB, and the computer is used only for APP and Photoshop, so, I'm not worried about the performance for anything else.

[HansKeesom]

by HansKeesom » Thu Aug 18, 2011 8:36 am

............

I also noticed that many people is referring to the CPU's performance, and even when I never mentioned before, the CPU performance using the 6 HDD configuration is very good (pretty much between 92 and 100%) see the image.

I think that I cannot do too much to improve the performance in this computer, a mean, I should start thinking in something new with SSD or SAS/SATA 6G, 64GB RAM and dual XEON E7 Processor.... but, it would be just a dream... ;-)

BTW: The PTGui benchmark link doesn't work, could you check it?

Hi Ronald,

From the screenshot it is clear you have enough memory and if the CPU% is this high during the whole process, it is clear the CPU is the bottleneck. There are ways to make your current CPU faster but you will end up in the land of the overclockers where things are a bit risky.
You might want to look in your BIOS to have a look at things like the multiplier. Sometimes you can increase it without disturbing the stability.

The decision to buy a new system I think depends on how much you can gain with it. Will it safe you one hour of your own time each and every day? or are you fine with having your machine run overnight, while you do other things?

Good luck.

Hans

[foundation]

by foundation » Fri Aug 19, 2011 1:46 am

or buy a cheap 2nd desktop and have it run 1/3rd of your panoramas.

[tived]

by tived » Fri Aug 19, 2011 2:07 am

Hi Ronald,

You may have many large image files, but with every image file, if you are running raw workflow as well, you will have a small side car file, in actual fact you will have many many small files which will take up alot of space because they will use one element size each. There has been some tests to show which sector size is the most efficient, sorry I can't find the link. I think it might be DigiLloyd on macperformance.com, disregard the OS, the principles are the same.

I am only running 64kb myself, which may not be the most efficient one, but without an upgrade to the controller it will not go up to 128kb, maybe later after xmas when I hopefully can expand my disk arrays.

thanks

Henrik

PS: I am not familiar with the error, sorry

[Ronald]

by Ronald » Fri Aug 19, 2011 5:16 am

Hans/Henrik,

Thanks you both for your comments...

Honestly, I never thought about a possible bottleneck due the CPU limitations; and, during the review of the results and CPU configurations in the Gigapixel Panorama Speedtest, I noticed that my CPU "issue", I just have two E5405 processors (2Ghz).

With my current configuration, I'm more than happy at least for now in terms of rendering peformance; in the upcoming months, I will try to upgrade to the X5470 processors (3.33Ghz) which should improve the performance dramatically... we'll see!

I'm aware that my particular RAID configuration would be affected by the presence of small files in the HDD's, and those little .xmp files generated by Photoshop during the RAW-->TIFF conversion are deleted all the time to avoid bottlenecks; and again, that computer is exclusive for APP/Photoshop, so, I'm not too worry about it.

BTW, few minutes ago I was double checking the issue reported yesterday about the critical error and I found something that in the middle of my sadness watching the Speedtest results, brought me some happyness...

The panorama used for the benchmark, shows the results below:
- Total benchmark time: 9 min:11 s (337 JPEG images avg. size around 200kb)
- Temporary data read/write: 75.6 MB/152 MB
***: Is really a poor performance using 6 HDD's in RAID-0 .... even worst looking at the speedtest results :-(

Then, I did generate a local panorama with the following results:
- Total benchmark time: 31 min:3 s (240 TIFF16 images avg. size 57.6MB)
- Temporary data read/write: 26.8 GB/26.9 GB
***: Yes, this panorama I did take 3 times more to be generated, however, looking the volume of data processed the numbers for me are not that bad, and confirms the Hans comments....

Yes, I did have a CPU bottleneck (and I will solve that situation in some point); however, I don't think that my HDD/RAID configuration is having any problem! :-)

Thanks,
Ron

Last edited by Ronald on Fri Aug 19, 2011 5:16 am, edited 1 time in total.

[HansKeesom]

by HansKeesom » Fri Aug 19, 2011 1:25 pm

Hi Ron,

You run the benchmark in 9 minutes, you run a test with your own set in 31 minutes.....you are in good shape, so what is the problem you want to solve?
What do you expect to gain from shaving of 10% of the time? Does it matter if you do the last set in 27 minutes instead of 31? Will that really bring you anything? And finally : will it be worth the investment.??
You are the one to answer these questions for yourself, like everyone has to do so...

Good luck,

Hans

[KreAture]

by KreAture » Fri Aug 19, 2011 5:32 pm

My new rebuild does the test in under 8 minutes. But, it still requires 6+ hours on some of my own panos.
The test simply has too low input complexity to properly simulate the advanced stitching of APx. I do use 3-layer stacks though. This test was not stacked.

[HansKeesom]

by HansKeesom » Fri Aug 19, 2011 6:08 pm

Kreature,

More important is what you think about these 6+ hours. Do you really want to improve on that or is it that you sleep 6+ hours anyway?

(Your comment shows that) everyone needs to look at the panoramas he/she makes him/herself and based on that find out whether or not their system needs an upgrade. A benchmark like the one we speak of is nice for comparing and feeling great, but has nothing to do with each and everyones businessmodel.

[HansKeesom]

by HansKeesom » Tue Aug 23, 2011 2:33 pm

Btw Hans... I just realized your tag... You'd have charged me €1098 for my large pano haha. (Edit it was 1098 images, not 2214)
http://kreature.org/oslo/oslo_from_ekeberg_2011-07-28_420mm_dehazed.htm

Edit:
My new i7 comp did it in about 2 hours.

Hi Kreature,

If you are able to do it yourself, that is fine of course. I know you have a big system running so you should do it yourself to earn back the investment. Not everyone can do such investment.
And of course, if your pano would run that smoothly I would give you a reduction ;-)

[HansKeesom]

by HansKeesom » Fri Aug 26, 2011 2:14 pm

Hans/Henrik,

...........
Honestly, I never thought about a possible bottleneck due the CPU limitations; and, during the review of the results and CPU configurations in the Gigapixel Panorama Speedtest, I noticed that my CPU "issue", I just have two E5405 processors (2Ghz).
..........
Yes, I did have a CPU bottleneck (and I will solve that situation in some point); however, I don't think that my HDD/RAID configuration is having any problem! :-)

Thanks,
Ron

Hi Ron,

I have to correct myself regarding the CPU-bottleneck thing. I thought I had a CPU-bottleneck, judging from wat I saw from the taskmanager and sourcecontrol. Oke, the pagefile was doing a decent amount of work, but nothing really troublesome. The test mentioned took me 5.5 hours but I hardly do panoramas that size.
So although it seemed useless to increase my memory, the low cost of an upgrade from 6 to 16 GB made me do it anyhow. Result : the test took only 24 minutes instead of 5.5 hours. 9 times as fast!!!!!! Not bad for a 145 euro investment........

Conclusion : even if CPU is very busy, going from few GB's to a decent number of GB s could bring you a lot for little money.

Note, of course, the panoramas I normally do are not done any faster.

regards,

Hans Keesom

Last edited by HansKeesom on Fri Aug 26, 2011 2:36 pm, edited 1 time in total.

[KreAture]

by KreAture » Fri Aug 26, 2011 3:39 pm

Yep. The thing that happened there was ammount of scratch-work and swapping. Grately reducing it saves a lot of time.
It's similar to my tests with 6 TB data re-read from the scratch on 4 GB mem, but only 56 GB read at 16GB mem, on same pano.
When it starts trashing you are doomed (to wait).

[HansKeesom]

by HansKeesom » Fri Aug 26, 2011 4:25 pm

5,5 hours was already acceptable after 9,5 hours. Only change then was moving pagefile from different harddisks to SSD. i guess that by adding memory, the pagefile is also less used.

At 11,1 GB used memory totally, the tempfiles and the pagefile became active. I would have expected APG to go on until close to 16 GB before doing that. Funny thing is that 11 GB is also the amount free I saw in the settings.

So in theory, if i could even more memory, things should go even faster with the same processor. Unfortunatelly the motherboard does not allow that....I think..

[KreAture]

by KreAture » Fri Aug 26, 2011 4:54 pm

Whoops! Wrong board, identical layout!

Last edited by KreAture on Fri Aug 26, 2011 8:06 pm, edited 1 time in total.

[HansKeesom]

by HansKeesom » Fri Aug 26, 2011 6:40 pm

Kreature, i don't see the relation between FEMM and the thread. :-)

Meanwhile, it is amazing how quickly one gets used to having more memory. I now run one time APG and two time PTP at the same time. As a result the 60 GB is getting full and APG starts using second tempdrive which is a harddisk.

Guess the next thing to do is giving the pagefile it's own SSD...... don't expect a 9 times accelleration there.....

[HansKeesom]

by HansKeesom » Wed Aug 31, 2011 7:26 pm

Hans/Henrik,

...........
Honestly, I never thought about a possible bottleneck due the CPU limitations; and, during the review of the results and CPU configurations in the Gigapixel Panorama Speedtest, I noticed that my CPU "issue", I just have two E5405 processors (2Ghz).
..........
Yes, I did have a CPU bottleneck (and I will solve that situation in some point); however, I don't think that my HDD/RAID configuration is having any problem! :-)

Thanks,
Ron

Hi Ron,

I have to correct myself regarding the CPU-bottleneck thing. I thought I had a CPU-bottleneck, judging from wat I saw from the taskmanager and sourcecontrol. Oke, the pagefile was doing a decent amount of work, but nothing really troublesome. The test mentioned took me 5.5 hours but I hardly do panoramas that size.
So although it seemed useless to increase my memory, the low cost of an upgrade from 6 to 16 GB made me do it anyhow. Result : the test took only 24 minutes instead of 5.5 hours. 9 times as fast!!!!!! Not bad for a 145 euro investment........

Conclusion : even if CPU is very busy, going from few GB's to a decent number of GB s could bring you a lot for little money.

Note, of course, the panoramas I normally do are not done any faster.

regards,

Hans Keesom

And the saga continues. Although I don't like overclocking I looked around and it wasn't that difficult for my I7. Upping the Host clock frequency was all I had to do.
I carefully moved it from 133 to 150 and did three tests. Instead of 24 minutes I now got a nice 15 min 04, 17 min 52 and 21 min 49.
So you see, if your CPU is the bottleneck there might be something you can do.

Using the programm Real Temp 3.60 I got good insight in how things work with my intel I7. Basicly it is about the temperature of the 4 cores, the TJMax of these cores and the host clock frequency and multiplier of the CPU.
When any of the cores hits the TJMax that is set for it, the CPU will start decreasing all kinds of things like the multiplier to prevent the core going over it's TJMax. Intel has set the TJMax for each core at 100 degree celsius so we can assume that to be a safe value and yo
Nevertheless I choose to put them on 95 degrees, just to be safe. Real Temp 3.60 allows you to set the TJMax for each core. Don't set it higher then the value that was initially there!!!

Using the free intel desktop control center software I could now change the host clock frequency and put my system in Intel Turbo Boost mode. Reboot and run it!

A.F.A.I.K. you can't go wrong here, the i7 will simple slow down when it gets too hot. Sounds like well protected. You can off course keep it from getting hot by taking good care of the cooling. My simple trick is to open the computers case and have a simple tablefan blow into it. Works all the time and allows the CPU to continue to run on high frequency and multiplier a bit longer.

With these simple steps I got an extra 10-40% of the time of the test, tada.