From: Greg Ercolano <erco@(email surpressed)> Subject: [Q+A] Using the rush 'Ram' value Date: Thu, 27 Jul 2006 03:57:43 -0400 |
Msg# 1354 View Complete Thread (1 article) | All Threads Last Next |
> If I set the ram value my job needs to the maximum amount of ram > the machines on our farm have, does that prevent the OS from > having enough ram left over for the operating system to do its work? No, that's not an issue. The ram value you supply to Rush when you submit your job does not actually constrain the amount of ram your render actually uses, nor reserves it from the OS. Rush doesn't even monitor your job's actual ram use. The ram numbers you supply to Rush are comparative, used only for decision making in whether to start a render running on a machine or not. When Rush wants to start a render running on an idle machine, rush looks at the ram value for that machine from your rush hosts file and compares that to the ram value your job is requesting. As long as the value your job is requesting isn't more than the machine has available, rush will start your render on that box. If there's not enough ram on the box, rush won't start the frame on the machine, and indicates this in the "NOTES" field of the irush 'Cpus' report for your job, eg: CPUSPEC[HOST] STATE [..] NOTES +any=20@100[tahoe] CpuPass2 [..] Ram unavailable on tahoe (4000>512) +any=20@100[meade] CpuPass2 [..] Ram unavailable on meade (4000>512) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In this case hosts 'tahoe' and 'meade' only have 512M of ram available, but the job is requesting 4000M, so the job is turned away on those processors. ANALOGY Think of the machine as a container for blocks, and your job's frames as the blocks. Rush needs to put as many blocks as it can in the container. Rush is told the size of the container (ram value configured in the rush hosts file) and the size of the blocks (the job's ram value). Based on priority, rush will put the blocks (frames) into the container until either there's no room for more, or until there's no more blocks. Rush is further constrained by not allowing more than so many blocks (cpus) in at a time, even though there might be enough room (ram) for more. Rush keeps a tally of the container size and blocks, and based on that tally determines if any more blocks can fit. Rush doesn't actually measure the container or the blocks (because they're volatile), it goes entirely by the values you tell it. EXAMPLE An example from the HOW-TO on 'Threaded Rendering': http://www.seriss.com/rush-current/rush/rush-techniques.html#Threading * * * If you have a farm of dual proc machines that all have a gig of ram configured in rush (eg. 'rush -lah' shows 1024 in the Ram column), and you submit a job with the 'ram' value set to '1024', then you will effectively secure both processors from rush. This is because when rush starts your render on a machine, it will subtract the ram value your job requests from the configured ram value for that machine, leaving zero available for other jobs to use. Also, you will only be able to start rendering on machines that have 1024 available, which means both processors must be unused by rush, otherwise rush will think less than 1024 is available, preventing your job from running on those machines. If you want to allow other renders to still be able to use the other processors, then submit with your Ram value set just a little bit lower, eg. 1023. You can then submit other renders to these machines by requesting a Ram value of 1, and they'll be able to get on because of the 1MB your job leaves behind; 1024-1023=1MB available. * * * The ram and cpu numbers are completely configurable; you can request more or less ram than your job actually needs, the sysadmin can configure the ram (and cpus) each machine has to be more or less than what the machine actually has available. The numbers are comparative only, and are just used for the decision making process of whether to run a render or not. Once the render kicks in, it can do whatever it wants. |