|02 February 2013||#16|
Join Date: May 2008
The thing with amazon is you have to supply your own software license, install and setup the OS, and get the VM's set up to network render. Pro renderfarms like Rebus and renderrocket supply the software for you and already have all the renderfarm network management working for you so that should rightfully increase the cost of using them – along with the fact that you don't have to spend 4 hours fiddling around learning how to get amazon to render your particular software.
I think it'd be a pain to set up the VM's as their own self contained renderfarm on a short notice, and even more of a pain if not impossible to work out the firewall, security, and network address issues to somehow tie it into your current local renderfarm or access your license server.
If you're using a 3d app that allows infinite rendernodes for free or if you want to attempt to set up and install throw-away trial editions of software that'll expire after 30 days, go for it. You have nothing to lose but time if it doesn't work.
On the flipside, if you're a working professional who needs a reliable bulletproof solution, then I'd still opt to use an established pro dedicated renderfarm and charge the client for the cost difference or pay it yourself if the rush time management problem was your fault.
Even if it's a rare occasion where you need a huge job rendered by tomorrow - I'd be even more inclined to pay for something that will absolutely get the job done in time without spending hours setting up cloud VM's that might end up just rendering out blank frames and leaving you with only 2/3 of the day left to render the files.
and I really do wish some of these render engine companies would update their licensing to not charge per machine, but rather charge for specific rendering features, speed optimizations, access to weekly beta builds with bug fixes, and different levels of tech support, etc.
Small studios often can't realistically afford to use some of the computationally expensive render settings. It doesn't do much good to have access to these high end features if they're too slow to actually use in production because you don't have enough machines. I think it's rather ironic and the wrong way to go about charging for render licensing.
Last edited by sentry66 : 02 February 2013 at 06:34 AM.
|02 February 2013||#17|
Join Date: Feb 2013
No,no, it works.
I made money with AWS EC2.
I ran 20 cc2.8xlarge in Spot Mode in a VPC.
My clients earn hours.
I'm working on Blender + Cycles in GPU.
There's a good strart.
Best Regards. (sorry for my poor english).
|05 May 2013||#18|
contract motion/3D designer
Bristol, United Kingdom
Join Date: Jun 2003
After a bit of 3dsmax/Backburner testing on EC2 instances...
Reawakening this thread as I've found very little on the topic of actual EC2 render performance (3dsmax) until we did some testing ourselves to better understand if it'd be something investing in over buying more kit in the office - here's what we found (based on a very basic setup, and not being particularly scientific so please consider this more anecdotal!)
1x Backburner 2012 running on m1.large (single socket 4 core xeon 2.5ghz)
4x 3DS Max 2013 running on CC2.8xlarge (dual socket 8 core xeon 2.6ghz)
In reality, the cpu specifications don't give the performance we originally expected. I'm not entirely sure why, but I'm sure hypervisors, some shared resources and other hidden stuff is getting in the way.
Compared with local machines we have, these are rough rendertimes for a test BB job:
Amazon EC2 CC2.8xlarge (XeonE5 2x8 cores @ 2.6GHz : 41.6GHz) 5 mins
Local Rendernode (SandyBridge i7 6 cores @ 3.2 : 19.2GHz) 6.5 mins
Local Workstation (Xeon E3 4 cores @ 3.5GHz : 14GHz) 10 mins
We were hoping to see the Amazon instances to be knocking frames out in 1.5x - 1.8x faster than a local renderbox can smash them so were a little disappointed when they were coming in at only 1.2x considering they supposedly had twice the raw available GHz. There were very little maps being used in the scene, and actual scene translation time was fairly minimal (precached geometry, no FG/GI, no proxys) and kept to around 15 secs. Once rendering the machines were using 100% of the available CPU resources (according to Task Manager).
In total it takes about 30 minutes to spin all 5 machines up from cold and get a file rendering via backburner. We've not yet got a successful VPN from an EC2 instance to our studio so having to transfer files off the EC2 instances via a webdav link so the bottleneck in our experience is with our download speed. In tests, we can shift approx 1GB a minute off the EC2 onto other cloud storage. note: Don't use Dropbox - it's hobbled to 400KBPs (it seems in the UK).
In summary - it could be very useful when needing extra juice during a panic (until we expand our local render kit). Probably works out to about £8/hour to employ 4 extra machines with minimal setup fuss. Downside is performance ain't all what we expected/hoped. Our studio internet connection is the biggest immediate problem (a fixed always on EFM to the green box sadly limited to 4mbps up/down for nearly £6K/year - thanks BT for never digging up the road around here!). Plugins/node licensing is a big unknown - will try krakatoa or Fume next time we need it and see what headaches that creates.
The 3ds max file we were testing with:
150meg layout file referencing a 120 meg XrefScene file
100 meg of bitmaps
Mental Ray, ray tracing, cached geometry, no render elements, no other caches/mr proxys
3840x1080 resolution, framebuffer off during render
No plugins or fancy stuff
Hope some of this was useful for other EC2 dabblers...
|05 May 2013||#19|
Join Date: Aug 2003
tutorial for setting up a Backburner render farm on Amazon'S EC2
|05 May 2013||#20|
Join Date: Jan 2007
I realize this is an old thread but while we're on the subject again I'd like to add something. A few applications come with support for rendering on Amazon EC2 out of the box. For example in Houdini you don't have to do anything special and they have machine images already setup for you. They had this back in 2009.
Like sentry66 said, Amazon is cheaper for a reason. If you're using software that requires licenses per machine those costs are already covered with other render farm services and they have a pipeline and queue manager already setup. There's also other charges to consider with Amazon like bandwidth and storage which are billed separately.
This can be a slippery slope, cloud computing in general can be very expensive compared to purchasing the equipment and software outright. If you need 50 machines for one day a year then cloud computing is a good way to go. If you need 50 machines five days a week all year long then cloud computing is a horrible idea and will end up costing many times more than setting up your own farm. It takes only a few months of regular usage for the costs of cloud computing to exceed that of purchasing outright (YMMV).
|05 May 2013||#21|
contract motion/3D designer
Bristol, United Kingdom
Join Date: Jun 2003
Olson - you're definitely right about long term cost implications for larger scale work - although specifically for the scale of our 3D projects it'll help when we needed to quickly get an unplanned render bashed out during the day to fix an issue and when we haven't set the scene to work with Rebus for whatever reason. It's a tool, which is good to know is at our disposal if it helps.
A well planned schedule and well specced project with properly allocated render resources are bare essentials to any project and from the few hours we've been sniffing out the EC2 machines with Backburner I think it still has it's place here and there, although it's not to be assumed it'll fit every project by any means.
|06 June 2013||#22|
Join Date: Dec 2012
ZYNC on EC2
I wanted to chime in here and let you know we've made ZYNC publicly available now with support for Maya/VRay/Mental Ray & Nuke. It's written on the EC2 backbone and manages all interaction (file i/o, licensing, storage) with render nodes on demand so it works and feels just like local resources. You can see a 10 min demo here:
and see pricing and signup info at www.zyncrender.com
|06 June 2013||#24|
Join Date: Dec 2004
8*1,7 ghz = 13,6ghz for 1,7$ per hour = 0,125$cent per ghz hour
16*2,6ghz= 41,6ghz for 3,7$ per hour = 0,089$cent per ghz hour
12core 2,4ghz 32gb ram (physical PC no instance)
0,039 €cent per ghz hour ~ 0,051 $cent - thats the basic price without discounts applied
unlimited number of nodes
no waiting time in farm
just one button to start render directly out of your 3d software
user support and live chat 24/7
and much more
I wished someone whould compare speed, costs and workflow with EC and Rebus
I am curriouse for the results
|06 June 2013||#26|
Join Date: Sep 2003
Thread automatically closed
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
|Thread Closed share thread|