Every render schedule comes down to the same three numbers: how many frames, how long each one takes, and how many machines you can throw at them. The arithmetic looks trivial until you notice that adding machines does not divide the time cleanly, that scene load can cost more than the render on a light frame, and that the frame you timed was not representative. This render time calculator takes your own measured per-frame figure and turns it into a wall-clock estimate, a node-hour total, a cost at your own rate, and the node count a deadline would demand.
Arb Digital builds free tools with sharp boundaries. The live GPU cost calculator estimates monthly cloud GPU spend for AI training and inference, which is a steady-state capacity question. This page is about a finite job with a fixed number of frames and a delivery date, which is a scheduling question, and the two share no arithmetic beyond the idea of an hourly rate.
What This Calculator Does
It reports four figures. The headline is the wall-clock time to finish the sequence on the number of nodes you have, which is the number a producer actually asks for. Underneath it are the single-machine time, so you can see what the farm is buying you; the node-hours the job bills, which is what a cloud invoice charges for; and the cost of those node-hours at whatever rate you enter.
The fourth result inverts the problem. Given a deadline, it returns the number of nodes needed to finish inside it, using the same scaling model. That is the figure worth having before a conversation about budget, because it converts "we need it by Friday" into a quantity you can price.
This page publishes no prices. Cloud rates, farm rates and the cost of electricity for machines you own all vary by provider, region, hardware and contract, so the rate is a field you fill in. If you are pricing machines you already own, our electricity bill calculator is a better starting point for the running cost than any published hourly figure.
How to Use It
- Measure the per-frame time properly. Render several frames from different parts of the sequence at final settings on the hardware you will use, and take the slowest rather than the average.
- Add the overhead separately. Scene load, cache reads and output writing happen on every frame and do not shrink when the render does.
- Enter the nodes you will really get. A farm with sixty machines that is running three jobs is not sixty nodes for your job.
- Set an honest efficiency. Ninety per cent is a reasonable default for a well-behaved frame-parallel job; heavy scenes on a busy network do worse.
- Read the deadline result before you commit. It tells you whether a date is achievable with the hardware available, or whether the conversation needs to be about the scene instead.
The Formula and the Scaling Model
Start with the work. Each frame takes the render time plus the fixed overhead, so total work in node-seconds is frames × (per-frame render time + overhead). That figure is the honest measure of the job's size and it does not change however many machines you use.
Then divide it by throughput. Rendering a sequence is close to an ideal parallel problem — frames are independent, so nodes barely need to talk to each other — but it is not perfectly parallel. The queue has to distribute work, the network has to feed assets to every node at once, and at the end of a job the last few frames leave most of the farm idle. The model used here counts the first node in full and discounts every additional node by the efficiency figure, so throughput is 1 + (N − 1) × e. At an efficiency of 100 per cent it reduces to plain N, which is the ideal case.
That shape comes from Amdahl's law, the standard account of why parallel speedup falls short of the number of processors. Duke's notes on Amdahl's law and parallel speedup set out how serial work and communication overhead cap the achievable gain, and James Madison University's chapter on the limits of parallelism and scaling gives the algebra together with the important caveat that the law deliberately ignores the cost of managing the extra workers, so real systems do slightly worse again.
Work the defaults. Fourteen hundred and forty frames at six minutes each, plus twenty seconds of overhead, is 380 seconds a frame, or 547,200 node-seconds — 152 node-hours of work. On one machine that is 152 hours. On eight nodes at 90 per cent efficiency the throughput is 1 + 7 × 0.9 = 7.3, so the wall clock is 547,200 ÷ 7.3 = 74,959 seconds, which is 20 hours 49 minutes. The speedup is 7.30 rather than 8. Billed node-hours are the wall clock multiplied by the node count, 74,959 × 8 ÷ 3,600 = 166.6, so you pay for 166.6 node-hours to get 152 hours of work done — the difference is what the inefficiency costs. For an eight-hour deadline you would need a throughput of 547,200 ÷ 28,800 = 19.0, which at 90 per cent efficiency means 21 nodes.
Why Real Render Times Refuse to Match the Estimate
The estimate is exactly as good as the per-frame figure you supply, and that figure is harder to obtain honestly than it looks. Render time is not a property of a project; it is a property of a frame, and it varies enormously within a single shot.
The main driver in a path-traced renderer is noise convergence. Sample counts, denoiser settings, the amount of indirect light and how much of the frame is glass, hair, volumetrics or a caustic all move the time per frame by multiples rather than percentages, which is why renderer documentation such as the Blender manual's guidance on reducing noise in Cycles is largely about buying time back. A frame where the camera pushes into a dark interior can take five times the frame before it.
Motion blur and depth of field both multiply cost. A frame with heavy motion blur samples the scene at many points in time, and a shallow depth of field widens the ray distribution — both of them need far more samples to reach the same noise floor.
Memory is the cliff edge rather than a slope. A scene that fits in GPU memory renders at one speed; the same scene a little larger spills to system memory or falls back to CPU and renders at a completely different one. No linear model predicts that, and it is the most common reason an estimate is wrong by an order of magnitude rather than a margin.
And there is everything outside the renderer: simulation caches that have to be read from a network share, licence servers, texture streaming, machines with different hardware in the same farm, and the pre-render work that never appears in a per-frame timing. Take the number this page gives you as a planning figure with a healthy margin on it, not a promise. Render three frames, use the slowest, and add contingency for the notes you have not received yet.
Where the Farm Stops Helping
The scaling model has a practical lesson in it that matters more than the arithmetic. Because throughput is 1 + (N − 1) × e, the benefit of each extra node is constant but the cost is too, so doubling the farm nearly halves the time right up until you run out of frames.
That is the real ceiling: you cannot use more nodes than you have frames, and long before that the tail dominates. With 100 frames on 90 nodes, the first pass finishes in one frame-time and the remaining ten frames occupy ten machines while eighty sit idle. Splitting frames into tiles or buckets recovers some of that, at the cost of the coordination overhead the efficiency figure is meant to represent.
The other ceiling is the per-frame overhead, which does not parallelise away. If a frame takes twenty seconds to render and twenty seconds to load, half your farm capacity is spent opening files, and no number of nodes changes that ratio. On light frames the fix is not more machines but batching several frames per task so the scene loads once. Watching the overhead field on this page while you change the per-frame time makes that trade-off visible immediately.
Finally, cost and time pull in opposite directions once efficiency is below 100 per cent. More nodes finish sooner but bill more node-hours, because the inefficiency is multiplied across every machine you are paying for. If the deadline is soft, fewer nodes is cheaper; if it is hard, the extra node-hours are what you are buying the date with.
How This Page Sits Beside Our Other Cost Tools
The boundary in one sentence: this page schedules a finite render job in frames and node-hours, while the GPU cost calculator estimates ongoing monthly cloud GPU spend and the electricity bill calculator costs the power drawn by machines you own.
Downstream of the render, the video file size calculator and the data storage converter size the output, and the timecode calculator converts frame numbers into timecode for delivery. If you are quoting the work rather than only scheduling it, the freelance hourly rate calculator handles the human side of the number, and the time duration calculator turns the wall clock into a calendar.
Arb Digital builds free calculators because genuinely useful pages earn attention and links. If you want tools, calculators or content built for your audience, we can help.
Browse All Free Tools Talk to Arb DigitalCommon Mistakes to Avoid
- Timing one easy frame — render time varies by multiples within a shot, so a single sample from a simple section understates the job badly.
- Assuming eight nodes means eight times faster — queueing, asset streaming and the idle tail at the end of a job all take a cut, which is what the efficiency figure represents.
- Ignoring per-frame overhead — on short frames the scene load can cost more than the render, and no amount of hardware parallelises it away.
- Forgetting re-renders — the frame count that matters is the one you will actually render, including the versions that come back after notes.
- Planning around a scene that nearly fits in memory — spilling out of GPU memory is a cliff, not a slope, and it breaks any linear estimate completely.
Related Free Tools From Arb Digital
Cost cloud capacity with the GPU cost calculator and machines you own with the electricity bill calculator. Size the output with the video file size calculator and the data storage converter, convert frames for delivery with the timecode calculator, price your time with the freelance hourly rate calculator, plan the schedule with the time duration calculator, and browse the rest in the free online tools hub.
Frequently Asked Questions
Multiply the frame count by the per-frame time including overhead to get the total work, then divide by the throughput your farm actually delivers. At 1,440 frames taking 380 seconds each, that is 152 node-hours of work, which eight nodes at 90 per cent efficiency finish in about 20 hours 49 minutes.
Because distribution is not free. The queue has to hand out work, every node pulls assets over the same network, and at the end of a job the last frames leave most of the farm idle. This is the ordinary consequence of Amdahl's law, and the efficiency field is where you account for it.
Ninety per cent is a fair default for frame-parallel rendering on a healthy farm. Drop it if your scenes are heavy to load, if the network is shared, or if the job has few frames relative to the number of nodes, because the idle tail then dominates.
Almost always because the per-frame figure was not representative. Noise convergence, motion blur, depth of field, volumetrics and how much of the frame is glass or hair all move the time by multiples, and a scene that spills out of GPU memory changes speed entirely. Time several frames and use the slowest.
Only through the rate you enter. This page publishes no prices, because cloud rates, farm rates and electricity costs vary by provider, region, hardware and contract. For machines you own, work out the running cost with the electricity bill calculator first.
Because the inefficiency is charged across every machine you are running. At less than perfect scaling, doubling the farm shortens the wall clock by slightly less than half but bills for slightly more total node-hours. That extra is what buys you the earlier delivery date.
The fixed work that happens on every frame regardless of render complexity: opening the scene, reading textures and caches, checking out a licence and writing the output. On a frame that renders in twenty seconds, twenty seconds of overhead doubles the job, and adding nodes does not help. Batching several frames per task does.
Yes — set the frame count to one. The scaling model then has nothing to distribute, so it returns the single-machine time, which is the correct answer. Splitting one frame across machines by tiles is a different technique with its own overhead that this model does not describe.
This page is a planning estimate, not a quotation or a guarantee. Real render times depend on scene complexity, sampling, memory behaviour and farm conditions that no formula can predict, so the result is only as reliable as the per-frame figure you supply and should carry a margin.
