Linux Lightwave Render Farm: Getting BNR (butterfly netrender) to work in Debian, and possibly others.
by Lonnie on Jan.14, 2009, under Linux
What can I say? it’s been somewhat of an adventure to get this functioning because the documentation is very sparse on the linux side! but after many hours of tinkering and with the help of Paul Lord and Joe Laffey, I’ve managed to get it running, and running well! To give you an idea, a scene that used to render for me in just over 4 minutes can now be rendered out in just over a minute with the addition of two linux render nodes.
Hopefully this guide will help you get a Linux render farm in action using Butterfly Net Render as well!
First of all I’ll give you a run down of my environment!
Render Controller:
Windows XP Professional, 64 bit
Lightwave 9.3
Butterfly Netrender 4.x
Linux Nodes:
HP Proliant ML 250
Quad Core Xeon, 2.33ghz
Debian Linux (Etch)
KDE
Wine 1.0.1-174 (Could not get this to work with Wine 0.9)
Windows Configuration
The first thing we did was install BNR and make sure that Linux support was selected, believe it or not, most people forget this step and don’t even realize it. If you forgot to do this, reinstall!
Follow the instructions and get the netrender folder shared, in our case, we shared it and then mapped a drive on the controller to that share called R:
Next, map another drive to your lightwave content folder and then map a drive to that share, in our case we lettered that one N:
Linux Configuration:
Install smbfs if it’s not already there, using apt-get install smbfs
Create two folders, I used /lightwave and /lightwave-content .. these will be our mount points
Mount the shared netrender (R:) folder to /lightwave, and mount the shared lightwave content folder (N:) to /lightwave-content
Set up wine drive letters, in my case, wine was installed as root so I did this by going into /root/.wine/dosdevices and creating some symlinks … make sure the drive letters match up with our windows controller, like so:
ln -s /lightwave r:
ln -s /lightwave-content n:
Make a folder somewhere for the netrender software, I just made a folder called /home/netrender and copied bnrclient and bnetnode.lw in there, but rename bnetnode.lw to bnetnode.load
There will be a file in the /lightwave share called lwext9.cfg, in my case it’s /lightwave/NETRENDER/lw9intel/lwext9.cfg .. I copied this file to /lightwave/NETRENDER/lw9intel/lwext9lnx.cfg and then edited this new file.. I changed all the paths to linux paths because the instructions alluded to this, though I’m not sure this is necessary since lwsn will be fired off using wine .. so far I’ve not noticed any problems, so go ahead and do it, but remember that you’ve done it :)
Edit your bnetnode.load file back in /home/netrender .. I’ll go over some of the important variables.By the way, important note! the bnetnode.lw file that ships with bnrclient has one major problem with it .. some of the lines have tab characters after the ending semicolon, check for these and remove them! the semicolon MUST be the final character or you’ll have issues that make no sense.. just trust me on this.
CONTROLLER_IP, should be the IP address of the controller, I think this is straight forward
COMPUTER_NAME and USERNAME, I set these both to rnode01 (or rnode02, rnode03… it doesn’t matter)
NODES, set this to the number of processors in the system! please note that each node consumes a license. SEE MY EDITS AT THE BOTTOM OF THIS ARTICLE
MFLOPS, according to Paul, this variable is no longer used so delete it! (if using bnr 4.x especially)
BNR_SCENEDIR, this is the linux path to the scene directory, in my case, /lightwave/NETRENDER/build
BNR_FRAMEDIR, similarly, mine is /lightwave/NETRENDER/framesThe next few variables are important to get right, so rather than explain them, I’ll put my configright here on the blog and it’ll make sense! if it doesn’t, do it anyway and just make sure the paths are correct to your environment :)
LINUX_LW_LWSN=wine “/lightwave/NETRENDER/lw9intel/programs/lwsn.exe”;
LINUX_LW_CFG=R:/NETRENDER/lw9intel/lwext9lnx.cfg;
LINUX_LW_TEMPDIR=/tmp;
LINUX_LWCONTENTDIR=/lightwave-content;
Note the command wine added to the front of LINUX_LW_LWSN above, this is important and not documented.
Once you’ve done all this, from within KDE, you can launch bnrclient …
cd /home/netrender;./bnrclient
If all goes well, you won’t see any errors and you’ll see 4 nodes (in my case) connecting to the controller, assuming that the controller is running! ;)
Controller Configuration:
I’m a linux guy and another person in our office maintains the controller, but what I can tell you as that you’ll see these new nodes pop up in the list, you’ll need to right click and select properties on each of these fellas and set the platform to Linux Lightwave, which is on one of them tabs
You’ll also want to make sure in the scene properties, once you’ve added a scene that is, that you’re pointing to your shared drive letter .. in my case, N:
Additional Tips:
Windows XP Professional has a 10 concurrent tcp connection limit, so one thing that I did that helps limit the number of connections to the controller is to utilize our pre-existing linux file server… What you say? I’ll explain!
I mount the xp shares on the linux file server as mentioned above, and then I RE-SHARE those mount points in samba … follow me? all my render nodes mount off of the file server at that point, which means I don’t have to have a seperate connection just for those shares. At any time, only the file server is mounting those shares over a single connection.. Think about it, if you had 5 nodes mounting the directories, that’s 5 connections being used up.. with thise configuration, you could have 9 nodes running and it’d still only be a single connection for the shared drives, brilliant I know. :)
That should do it!
If you found this helpful, please consider a donation!
If you have a question you’d like me to try to solve, go ahead and ask it :)
Edit (number of nodes):
In the first version above, I pointed out that nodes should be set to the number of CPU’s that you have in the machine, which is probably what was intended by the authors of the software, however, when you do this you end up maxing out the system which can cause it to freeze up entirely or drastically degrade performance.
I would configure as such:
1 Processor: Upgrade your system!
2 Processors: 1 node
3 Processors: 2 nodes
4 Processors: 2 nodes for intensive scenes, 3 nodes for light renders.
Tweaking the number of nodes really makes a difference, we noticed that in our quad core machines that dropping the node count to two rather than four increased performance by about 30%
Also note that when I say “Processor” you could also consider that the total number of cores in the machine, if you have one physical processor but it’s dual core, then consider it 2 processors and configure a single node.
Another Update:
I noticed I was mentioned (albeit briefly) in the January Newtek Newsletter as an alternative to their screamernet on wine article ..
Incoming search terms:
- butterfly net render crack
- butterfly net render linux
- lightwave render farm ubuntu
- linux render farm
- renderfarm software
7 Comments for this entry
1 Trackback or Pingback for this entry
-
Incoherent Ramblings » Blog Archive » ButterflyNetRender on Linux
February 13th, 2009 on 7:46 am[...] initially followed the “authoratitive” source for configuring BNR on Linux (found here) which was absolutely excellent. However, I found that the native BNR client for Linux seemed a [...]
February 9th, 2009 on 12:02 pm
Hi, cool site, good writing ;)
February 27th, 2009 on 5:24 pm
Hi Lonnie – nice writeup! :) How can I get you to try out our brand new linux render farm software and tell us what you think??
We are trying to improve the state of the art when it comes to scaling out linux render farms in no time flat, and we need beta testers. Since you have this experience doing it with BNR, I’d REALLY value your opinion.
Thanks,
Chris
March 2nd, 2009 on 11:12 pm
Chris,
I’d be happy to give it a shot, is there anything in particular I need to know? Always interested in such things, and I’d be happy to write up my honest views :)
Lonnie
March 4th, 2009 on 6:39 pm
Chris,
Still waiting to hear back :)
March 5th, 2009 on 11:54 am
Sorry Lonnie! I’m back… Well, all you need to try it out is a Centos 5.x box and a copy of our software.
Specifically you need the renderfarmer download from here: http://www.linuxrenderfarm.com/downloads/rs-renderfarmer-1.1.tar.gz
And the installation guide is here:
http://www.linuxrenderfarm.com/documentation/cluster-maker-and-render-farmer-installation.html
I am revising that now because some of it is dated, but not so much that it doesn’t work.
Pre Req’s are short:
* Does /etc/hosts have the correct information?
* Is the system configured with the primary IP address on eth0? Primary means: This is the IP that the master will use to communicate with clients. I.e., if I am 10.0.0.5 and the clients will be 10.0.0.6,7,and 8., then 10.0.0.5 needs to be on eth0
* Is your kernel source linked to /usr/src/linux ? (for tips on obtaining this, check the latest README documents) The source headers provided by yum install kernel-devel are fine.
You’ll want a few nodes that you can set for PXE boot too…
And thanks! Let me know how it’s going and I look forward to hearing what you think.
March 16th, 2009 on 7:05 am
Chris,
I do still intend to look at this, the only issue at hand is that it requires Centos and I don’t have a spare machine readily available to wipe out for that OS .. We run a Debian network, it’d be wonderful if a Debian package were available.
I could run this in a virtual environment but I don’t think that would be very fair to the software since performance would be greatly impaired… so I’ll see what I can do to set up a test.
March 17th, 2009 on 9:36 pm
Thanks Lonnie, good feedback. I should put a poll up on my site to ask specifically which distro people want to use for render farms. Debian / Ubuntu is next on the list anyway!
There is nothing inherently incompatible about the software, just all the ancillary tools that I need to worry about handling. Like using apt-get instead of yum (and finding the right package names), update-rc.d instead of chkconfig, etc. Nothing huge but it will take me some time.
You are correct that performance is only so-so in vmware, but it does work. One cool thing is that an empty vmware client can be set to PXE boot, kind of like a virtual diskless node, and that works pretty well on the client side. But for server side, a physical box is much better. Keep me in the loop, I look forward to hearing how it goes. Also, if you have downloaded a version already, check again before you install. A newer one will probably be up.
Thanks!