Tech Support Blog

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Monday, 24 August 2009

12 GB For the RenderFarm

Posted on 08:40 by Unknown
The global scenery gets cut on "the renderfarm", which is our name for the cluster of computers, each loaded with all of the input data for the global scenery. These computers chug for a few days to churn out the whole planet.

With the next global render I am trying an experiment: using one 8-core Mac Pro as the RenderFarm. We've never had more than 8 processors in the farm at a time; in the past to get 5 processors might have taken 3 machines. The appeal of a single machine is ease of setup; no data to sync between machines, no sorting out which machine did which tile and merging it all back.

Today I upgraded the Mac Pro's memory (again) to 12 GB. I thought the logic of why I did this might be of interest to X-Plane users who are trying to figure out "should I have more memory"?

Basically there are three memory limits we care about:
  1. The virtual memory limit per process - generally 3 GB per process for a 32-bit application. If an application wants more memory tan this, regardless of what you have, it is dead.
  2. The virtual memory limit for the whole machine. Since the machine virtual memory limit is a function of hard disk space, normal users will never care about this - we can have a huge amount of virtual memory.
  3. The physical memory actually used by the sum of all programs actually running. Once all programs need more physical memory than you have, they start using hard drive, and they get really, really, really slow.
In the case of the render farm, our processing program runs on one DSF tile at a time. But with 18,000+ tiles we can take advantage of more cores by processing 8 tiles (using 8 copies of the program running at once) on 8 cores.

This is where memory comes in. Before the upgrade my machine had 4 GB of memory, allowing each of the 8 tiles to use a little bit less than 512 MB of RAM before we ran out of physical memory and started paging. (The OS takes a little bit for itself.)

Normally this is all good -- a typical run might only use 300 MB of RAM. But every now and then we hit New York City or Boston and the RAM use spikes out to 1500 MB or more.

This is okay if just one process hits New York, but what if a bunch of processes hit a big city at once? We blow past the physical RAM of the machine and every tile becomes slow at once. And because they are all slow at once, they take a very long time (hours) to clear this state.

(This state of thrash due to many processes is like 8 people trying to go through a doorway at once. If they would just take turns, they'd be through in a second. But by forcing 8 at once they get stuck. The operating system won't pause a few of the high-memory programs to let the others complete.)

Since the RenderFarm has to run overnight unattended, I upgraded RAM to 12 GB, for 1500 MB per rpocess before thrash. My hope is that for this investment, we'll be able to run the processing through without a human to unjam it.

What About X-Plane

So would a RAM upgrade for X-Plane help? Well we can apply what we know from above to figure it out. Generally, you need enough RAM that X-Plane + all other programs won't run out of physical memory. Since X-Plane is 32-bit (and can only use 3 GB of RAM) you are likely to be fine with 4 GB when running X-Plane + the OS. Any more and X-Plane can't take advantage.

The exception might be if you need to run X-Plane and another big program like PhotoShop at the same time. At that point you might want enough RAM for both to run at the same time.
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in global scenery, hardware | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Pixel Shaders and Moore's Law
    In my post on 64-bit computing and X-Plane, there's a point that's implicit: there is a cost (in development time) to adopting any ...
  • Hierarchy and WED
    I just finished fixing some bugs in WED regarding the hierarchy view. (To get a sense of what a hierarchy view is like, try AC3D...) In WED...
  • Is Bigger Always Better?
    We've been preaching "one big texture, not lots of little textures" for a while now, and generally speaking, packing a lot of ...
  • Systems Modeling and Physics Modeling
    In past blog posts I have tried to contrast two very different different approaches to simulation, which I would loosely call: "Predic...
  • How Framerate Dies - Glitching
    Back in the good old days (that would be X-Plane 6), X-Plane's framerate would suffer in two ways as you cranked up the rendering option...
  • The X-Desktop and iPhone Are Not Zero-Sum Games
    On the menu this morning: first a whiny rant, then a nerdy one. Someone pointed me at this post. Before I go into my geeky diatribe about l...
  • Clean Airport Layouts
    I have blogged about correct airport layouts before, but let me bring the point up again, because it is so important: You must create struc...
  • So How Big of a Mesh Can You Build?
    I get asked about the maximum mesh density in X-Plane a lot. First, I must note that X-Plane's mesh is adaptive - the triangles are not ...
  • What is a panel region?
    X-Plane 9 introduces a new OBJ feature: panel regions. The basic idea is this: In X-Plane 8 you could use the 2-d panel as a texture in you...
  • Why Do Custom Lights Use the Object Texture?
    I am trying to be disciplined and put documentation on the X-Plane wiki , and limit the blog to announcements, rants, and explanations of wh...

Categories

  • absurdly cute
  • Air Traffic Control
  • aircraft
  • Android
  • animation
  • announce
  • cockpits
  • documentation
  • drivers
  • file formats
  • global scenery
  • Goofy Screenshots
  • hacks
  • hardware
  • hobbies
  • inside x-plane
  • installer
  • ipad
  • iphone
  • legal
  • localization
  • modeling
  • off topic
  • palm pre
  • panels
  • performance
  • plugins
  • political
  • scenery system
  • tools
  • X-Plane 10
  • XSquawkBox

Blog Archive

  • ►  2011 (12)
    • ►  February (1)
    • ►  January (11)
  • ►  2010 (111)
    • ►  December (4)
    • ►  November (4)
    • ►  October (10)
    • ►  September (9)
    • ►  August (12)
    • ►  July (8)
    • ►  June (4)
    • ►  May (13)
    • ►  April (13)
    • ►  March (11)
    • ►  February (12)
    • ►  January (11)
  • ▼  2009 (130)
    • ►  December (16)
    • ►  November (11)
    • ►  October (6)
    • ►  September (16)
    • ▼  August (12)
      • Two Warnings About Normal Maps
      • Plugin Broken? It's Temporary
      • A Slow Motion Car Crash
      • A Tip For Updating Electrical Systems
      • Driver Thrash
      • 12 GB For the RenderFarm
      • Lego Brick Code
      • Tweaking the Prop Disc in 940
      • 940 Beta 2 - Recovert Airplanes
      • Normal Maps in X-Plane 940
      • More Threads
      • I am the Spam King!
    • ►  July (11)
    • ►  June (9)
    • ►  May (5)
    • ►  April (10)
    • ►  March (9)
    • ►  February (9)
    • ►  January (16)
  • ►  2008 (147)
    • ►  December (18)
    • ►  November (10)
    • ►  October (7)
    • ►  September (11)
    • ►  August (15)
    • ►  July (9)
    • ►  June (14)
    • ►  May (9)
    • ►  April (14)
    • ►  March (13)
    • ►  February (6)
    • ►  January (21)
  • ►  2007 (100)
    • ►  December (17)
    • ►  November (13)
    • ►  October (13)
    • ►  September (9)
    • ►  August (17)
    • ►  July (7)
    • ►  June (4)
    • ►  May (6)
    • ►  April (9)
    • ►  March (2)
    • ►  February (3)
Powered by Blogger.

About Me

Unknown
View my complete profile