By Ed Mag (Ed_M) (64.12.105.166) on Tuesday, March 19, 2002 - 05:27 pm:

OK, I started this thread because of continuing issues with NewTek's product offerings for the Macintosh platform. Regardless of what the developers at NewTek are telling us, we all know that something is amiss (somewhere). Many of us believe that more effort and emphasis should be put into/on Mac development and optimization. Many Mac users are still feeling neglected and feel like second class citizens. Think about it, when will Lightwave at least reach "parity" with the PC version? Sheesh! We all hear the market share stories and the like, but wouldn't it be nice if one company broke the goose-stride and instead ignored market share in favor of better technology (i.e., the Mac)? Well, here is NewTek's chance.

Now they will have the opportunity to be the first company (in a long time) to be able to add a significant feature to their product making it something that's "Macintosh only". In this discussion I hope to attract some real interest in the area of "clustering" for faster render times. I've hinted at this on other posts, suggesting the complete inadequacy of ScreamerNet and how it is implemented on the Mac. I haven't used it, but from what I've been reading, it's rather "clunky".

Beofore I proceed, please keep in mind that in no way is this post intended to bash NewTek, their products or their developers. It is meant to grab their attention in hopes that they will start listening to their loyal Macintosh customers. The people who have invested a great deal of money in their products. Again, Let me say that I LIKE NewTek. If I didn't, I wouldn't bother posting to the forum. Hopefully they will take this opportunity to give the Mac community something unique. Anyway, let me get on with what I propose.

A few days ago, I took the liberty of e-mailing Dean Dauger, one of the Scientists working on Project: AppleSeed. I'm sure all of us are familiar with *that* by now. Anyway I asked him if it were possible to bring a simpler, more elegant and far superior (speed wise) clustered solution to the Mac that could replace the current incarnation of ScreamerNet. In short, Dean replied with a resounding: "yes".

Let me post my initial e-mail and then his reply just to give you a flavor. If all goes as planned, Dean will be contributing to this discussion (as did Chris Cox if you remember). Anyway, here is the exchange:

My e-mail:

[[[Hello DR, Dauger, I've been keeping abreast of what you've been doing in the Macintosh clustering arena and find it completely fascinating.

One area that Mac clusters would shine is in the world of 3D rendering / modeling. I've been lurking around the NewTek forums and constantly find that people are having difficulty with NewTek's distributed render solution called "ScreamerNet". The developers obviously have some implementation problems and as a result users of Lightwave are looking for other solutions for distributed computing. One thing I found interesting was this little snippet:

[[[ I noticed the following link http://www.vvertex.com/ which took me to a site having a "distributing rendering solution", "Muster".

It supports LightWave and I was fascinated by the following quote,

"With the core of Muster built on BSD sockets, we approach
TCP/IP in a native way, using a proprietary protocol built on the
TCP/IP stack, giving us the ability to develop a cross-platform
solution that works under NT, RedHat Linux 6.2 and Irix as well.
And this is not all. Due to the Unix roots of the new Macintosh
OS, Mac OS X, we are on the way of releasing a full-functional
render client for Macintosh." ]]]

Taken from a discussion found here:

http://www.newtek.com/discus/messages/2/15420.html?1016138168

I hope you take some time to visit the site. Perhaps you could even open a dialogue with the NewTek engineers and programmers to see if something vastly easier and significantly faster can be achieved (with a better distributed computing approach). Perhaps something along the lines of this product:

http://www.vvertex.com/

Let me know what you think.

Best
--
Ed M. ]]]


Dr. Dauger's reply:

[[[
Hi,

Thanks a lot for your interest!

I had a look through the sites. Yes, I agree with you that it should be
possible to link the Mac clustering technology with renderers like
LightWave. I would be happy to provide them direct technical assistance to
make that happen, but the trouble I run into when I talk to some of these
people is persuading the developers to proceed. I wonder if a grassroots
letter writing campaign is needed.

It's not clear to me from the discussion that you pointed out who to talk to
about this. Do you have any suggestions?

Thanks,
Dean ]]]

That was the initial e-mail exchange and there were others. As you can see, he's really excited about the possibility of bringing his great clustering capabilities to Lightwave for the Mac. I believe his unique "ease of set up" and more robust solution for Mac clustering would be a perfect candidate to replace the current ScreamerNet. All he asks is to sit and talk with the *right* people over at NewTek to get the ball rolling. He also hopes that Mac users will contribute to this forum in hopes of gaining support for the idea. Let's face it, NewTek has *just now* been given the opportunity to offer something unique to their Mac customers. Let's hope they finally listen. Again, spread the word if you or anyone you know is interested in superior render farm clustering that is simple, more elegant and vastly more powerful than ScreamerNet. I think this will be great for the loyal Mac-using customers as well as NewTek in general.

By the way, Dean Dauger can be reached here: d@daugerresearch.com

Pleas e-mail him and let him know you are interested.

Best

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Wednesday, March 20, 2002 - 09:19 am:

Sounds fascinating. What, exactly, needs to be done? Where does this "ease-of-setup" come from? How would a cluster-based renderfarm differ from the current LAN-based implementation?

By Mike Stening (Mike_Stening) (213.235.9.84) on Wednesday, March 20, 2002 - 09:27 am:

sounds interesting, i wanna know more..

By Marcel Valcarce (Marcelval) (65.214.183.163) on Wednesday, March 20, 2002 - 01:52 pm:

I think sonething like this is far overdue. I have been frustrated again and again by screamernet (they called it that because that is what it makes you do when you try to use it).

By Beam Tracer (Beamtracer) (198.142.203.106) on Wednesday, March 20, 2002 - 03:34 pm:

There were rumors going around that Apple was working on some kind of clustering scheme on an OS level. Maybe using the WiFi wireless standard (ie Airport).

Anyway, I think Apple's future is in getting many processors working together, whether in a distributed way or multiple processors working in the same box, or even on the same chip. OS X should make this possible.

I look forward to hearing more detail about the proposal that Ed mentions. Ease of use is an important thing, as I believe most Lightwave (and other 3D) users want to spend their time being creative rather than technical. Maybe Dean could elaborate on how such a system would improve the ease of use.

By Ed Mag (Ed_M) (152.163.201.51) on Wednesday, March 20, 2002 - 05:45 pm:

OK a few things... I'll tackle comments in order.

- Arnie

[[[Sounds fascinating. What, exactly, needs to be done? ]]]

Well, that is exactly what Dean want to discuss with the engineers at NewTek. I'll be keeping in close touch with Dean on this one. He'll let me know if NewTek is sandbagging him. His offer is genuine.

[[[Where does this "ease-of-setup" come from?]]]

Arnie, you seem skeptical. Anyway, in a particular article, Dean compares his Mac clusters with PC/LINUX clusters. As it turns out, Mac clusters are far more flexible, far easier to implement and provide faster performance.

[[["There's a book called How to Build a Better Beowulf that's 230 pages long and tells you how to set up clusters with LINUX," Dauger said. "We have a one-page manual (PDF) that shows you how to do it on PowerMacs. We've had high school students do it. We've had junior high school students do it. We even had a sixth grader in Hawaii do it." ]]]

You really have to read the entire article.

Found here: http://www.wired.com/news/mac/0,2125,50078,00.html

So, Mac clusters are more powerful than Pentium clusters and are roughly 230 times easier to setup :-) But I already stated this a while ago in another post on this topic.

[[[How would a cluster-based renderfarm differ from the current LAN-based implementation? ]]]

Beats me, let's wait for Dean to reply or better yet, you can contact him yourself. The goes for anyone else who is interested. Dean is a nice guy and looks forward to feedback.

- Mike

Mike, I'm working on it. Dean is out of town for a bit. Here is a recent e-mail I received from him:

[[[ Hi Ed,

I really like your suggestions and the direction you're going. Yes, please
do start as many new threads on this as you see fit. Just to let you know,
I'm flying out to Montreal today for a presentation with Apple Canada, so I
won't be back until the end of the week. My responsiveness until I get back
will be spotty, at best. After that I'll be around for a while. ]]]

So, Dean is seriously interested in working with NewTek on bringing a unique render/cluster to the Mac.


Thanks,
Dean ]]]

-- Marcel

[[[I think something like this is far overdue. I have been frustrated again and again by screamernet (they called it that because that is what it makes you do when you try to use it). ]]]

I couldn't agree with you more. Something along the lines of an "Autosensing" mechanism can probably be implemented and all you would have to do is make sure that the Macs are somehow connected. I'm not certain on the details. Only Dean knows for sure, but we can bet that Dean's approach and implementation will be a massive improvement on all aspects. That *is* his goal after all. ;-)

-- Beam.

BTW, always glad to see you Beam ;-)

[[[There were rumors going around that Apple was working on some kind of clustering scheme on an OS level. ]]]

Yeah, I was discussing this with Kelly over at osOpinion a while ago. Think of it as "plug-and-play-clustering" that actually works and something that would be built into every Mac... I bet Apple already has something implemented. Of course we are only guessing, but it sounds great.

[[[Ease of use is an important thing, as I believe most Lightwave (and other 3D) users want to spend their time being creative rather than technical. ]]]

Exactly. And the implementation should be simple, robust, yet offer superior performance. There should be as little tinkering as possible.

[[[Maybe Dean could elaborate on how such a system would improve the ease of use.]]]

I'm sure he will pop in on this forum. I e-mailed him so I know he's aware of it. He's busy in Canada at the moment.

Considering how things are going with Mac development over at NewTek lately, I feel that it would be in NewTek's best interest to seize this opportunity with Dean and also capitalize on the earlier offer from Chris Cox. In any event, anyone keeping track of these forums now know for sure that NewTek has been latterly *handed* two distinct opportunities to polish their Mac development into something exceptional rather than where it is now. Right now it would seem that NewTek, along with other cross-platform developers are primarily focussing on the PC market where they are marching in perfect goose-step. These companies should really diversify more. I mean does everyone have to go for the "easy target"? There is a real danger in placing all of your eggs in one basket. Micor$oft is going through some tough times and I wonder when these development houses are going to stop dragging around that dead horse... I wonder how Adobe does it? They literally put like 5 times the effort into their PC products and yet their Mac products still outshine the PC counterparts in many respects. I'm sure Chris will be popping in and out of the forums from time to time too. The point is that we are ALL witness to these opportunities for NewTek to vastly improve their Mac offerings.

--
Ed M.

PS: Keep spreading the word to other Mac users of Lightwave and have them post their comments to this forum, e-mail Dean directly and contact NewTek *directly* about this as well.

By Arnie (Arnie) (65.184.20.249) on Wednesday, March 20, 2002 - 07:09 pm:

It is my understanding that clusters a la Beowulf are a low-cost, homebrew replacement for massively parallel supercomputers. In this case, a rendering application would need to be coded from the ground up for this type of execution, and even then would probably not perform very well. The main problem, IMHO, is that the resources for rendering a scene are large, so every node in the cluster would need to duplicate the scene database, textures, etc. Adding the complication of raytraced reflections and refraction means that the computation of any pixel value can rely on any other part of the scene, so efficient parallelization is limited by the overhead of synchronizing scene data among the nodes and/or performing redundant data transformations.

This is the reason for my scepticism. The fact that Mac clusters are easier to set up than Linux clusters is irrelevant if a cluster architecture is not suitable for rendering. If Muster already works with screamernet, then it is all already good. I also wonder of the cost-effectiveness of mac-based clusters. As long as you can't buy a fast MacOS machine WITHOUT graphics HW, firewire, etc. then you will be paying for stuff you don't need, and the Mac's benefit of well integrated advanced HW is turned to a liability.


I won't take offense at the blithe assertion "Considering how things are going with Mac development lately...", but I will deny the premise that the mac product is some sort of second class citizen. That is simply wrong. Mac and PC releases are simultaneous, and the features (and bugs) are mostly identical. If PhotoShop is such an engineering marvel, where is the OSX version?

Also, these opportunities you suggest are largely fantasy, so the fact that no immediate concrete action is taken to get 3D floating-point tips from a 2D integer programmer, or to rewrite the renderer to accomodate a questionable architecture, MUST NOT be taken as neglect of the Mac or its users. Recall that most of the core LW team traces its roots at least to the Amiga, and loathes MS more than mac zealots do. Now that Macs sport an industrial strength OS, I can work a platform that doesn't make me feel dirty.

By Beam Tracer (Beamtracer) (198.142.208.124) on Wednesday, March 20, 2002 - 11:40 pm:

There are standard add-ons to the Macintosh like Firewire and graphics cards, but there are also add-ons that make clustering more appealing. Things like giga-ethernet, and the OS itself. Giga-ethernet comes with a giga-price if you buy one of these cards separately for the a Windows box.

If you want to cluster 200 computers together, then maybe a generic PC would be the cheapest way to go. However, I believe there would be a market for easy clustering on the Mac.

Many small/medium sized CG businesses would like easy clustering. When you have a small number of machines, during the day they may be used by individual people. When everyone goes home at night, they could be set up in a cluster to do a big render overnight.

So while the mega-cluster of 200 generic PCs may always stay as a render farm, the smaller Mac cluster may switch in and out of this mode. This is where the ease-of-use would be handy, and where the Mac hardware features are not a liablity.

There are presently many functions on the Windows version of Lightwave that don't work on the Mac. I gather that some of the main ones (spheres, Quicktime, UV Bumps) are the result of bugs. We love using Lighgtwave and appreciate the efforts of Newtek to bring LW to OS X. However with such basic features inoperable, the Mac users sometimes feel a bit neglected.

On the other side, I don't know of any features that Mac Lightwave has that the Windows one doesn't. Maybe, now that OS X is the norm, it would be possible to bring features to the Mac Lightwave that the Windows version could never do. Mac specific features are a great selling point, as other (inferior) 3D programs like 3DSmax could never match them. Maybe the clustering idea mentioned above is one of those features.

By Chris Cox (Chriscox) (192.150.11.14) on Thursday, March 21, 2002 - 12:24 am:

"If PhotoShop is such an engineering marvel, where is the OSX version?"

Shipping within the next month. Sorry it took a while, but Apple had a few bugs to fix.
BTW - the product is "Photoshop", no inter-cap.


"no immediate concrete action is taken to get 3D floating-point tips from a 2D integer programmer"

Gee, someone hasn't read my resume (of course, my online version is REALLY out of date) and hasn't bothered to find out what my background really is.....
And they reason they haven't done much is because I haven't had the time, and won't have until after PS 7 ships.

By phubear (Phu3dmac) (64.24.72.197) on Thursday, March 21, 2002 - 01:17 am:

Possibly a stupid suggestion, but could Apple's new Remote Desktop technology work with some integration into a Cluster GUI? Looks like it can boss around other stations pretty well...

By Beam Tracer (Beamtracer) (198.142.201.135) on Thursday, March 21, 2002 - 04:08 am:

Chis said "Sorry it [Photoshop] took a while, but Apple had a few bugs to fix." Hmmm. Reading between the lines, if Apple are to provide any fixes, then they must do it with an update to OS X. Hopefully that means OS X 10.2 will be out sometime soon.

Photoshop has always been a defacto benchmark for testing the speed of Apple machines. Steve Jobs traditionally used Photoshop to demonstrate the power of Apple computers at MacWorld keynote addresses. In fact, Apple even have a page on their website devoted to Chris Cox:
http://www.apple.com/creative/ama/0202s/photoshop/
It seems like Apple thinks that Chris Cox really knows how to optimize an application.

By Beam Tracer (Beamtracer) (198.142.202.168) on Thursday, March 21, 2002 - 07:29 am:

On re-reading some of the above posts, I wish to make a point a bit clearer.

I strongly disagree with the assertion that the Mac architecture is not suitable for rendering, or is a liability with regard to clustering.

I make animations for broadcast, using Lightwave in a 100% Mac environment. Animating always requires a lot of CPU power due to the enormous number of frames needed, so using as many CPUs as possible is the answer. Did I choose the wrong platform? If the Mac is unsuitable for rendering or use in a cluster, then it is unsuitable for animation.

As I said in an earlier post, I think there would be quite a number of smaller production houses that would like to link 10 or less Macs together. Such a set-up is not large enough to make feature films, but is suitable for broadcast animations of a few minutes duration or less. On this scale, there may not be a dedicated person to look after the render-farm, so ease of use is paramount, and the Mac has a real advantage as a renderer.

By ted devlin (Eblue) (12.149.3.2) on Thursday, March 21, 2002 - 09:33 am:

"Sounds fascinating. What, exactly, needs to be done? Where does this "ease-of-setup" come from? How would a cluster-based renderfarm differ from the current LAN-based implementation?"

can we back up a minute here?

I like the ease of setup thing, and i could care less, right now, if it was clustered. clustering offers speed, thats it. I want easy first, then smart, and finally give me speeeed!

Screamernet is waaaaaay out of date, and stealthnet was a good start in the right direction, but far from complete (especially since it never shipped on the mac!).

If Newtek is ever going to consider a complete re-make of screamernet, heres what I want:
1. a service (this is a feature of MacOSX, similar to a faceless app but more powerful, the apple dev team knows a lot about this) based renderer, that renders for both the network portion of the package and LW itself.

2. a configuration app that simply sets the variables for the renderer. and allows a gui start stop and restart of the renderer, among other things

3. One Setting that acts as a filter, its a list of ip adresses, or compuer names, whatever is appropriate, that tells the node who it can obey. It can get all of the other pertinent data from that computer when it wants to give it up. Heck, that can be a function of the renderer controller , to be able to ftp binary files to the render nodes, as needed, that way screw filesharing, you don't need it. (right now apple is hosting lots of interesting web pages about encapsulating unix commands inside your code, and beleive me its EASY).

4. a command line interface for the renderer service, ideally any gui tools should be built around these command line tools (hire a unix programmer he'll get it).

5. a controller app that runs the animation (this can also be built into LW such that this network renderer is the only renderer you need). you can search for ip addresses that have the renderer service running, you can enter them directly, you can write up a list to search through. you can set the parameters of the render nodes, load multiple files, choose which machines will do which renders (if youd rather wor that way) you can break up renders by frame field, region etc... and send the pieces out to the nodes. You can have N number of render controllers on a render farm, each with its own controller and renders to perform, and the nodes will accept or decline based on user preferences and just how busy it is. This way Two guys can share a network renderer while working and if one guy is away from te desk, the other guy gets that extra cpu power for his render.

it sounds like chaos, but its smart, easy to set up and configure, and way flexible.

By Arnie (Arnie) (65.184.20.249) on Thursday, March 21, 2002 - 10:07 am:

Beam, I haven't seen anyone assert that the Mac is not suitable for rendering. It is a cluster architecture that MAY not be suitable. This architecture would be the same on Mac Linux, or maybe even windows.

Chris, no offense intended to you or photoshop. Indeed I have not seen your resume. Sanjay from Apple did a good amount of work vectorizing the core rendering code for altivec. Do you know him?

By Chris Cox (Chriscox) (192.150.11.13) on Thursday, March 21, 2002 - 09:51 pm:

Arnie - yes, I know Sanjay Patel. I've been working with his team and the rest of the hardware performance folks for years.

Have you seed the CHUD toolkit that they recently released? It's really useful to find problem areas in your code. Unfortunately, you still have to know a lot about the system architecture to use it (and I do mean system: bus, board AND CPU).

By Ted Lee (Tedlee) (66.56.74.199) on Friday, March 22, 2002 - 10:20 am:

The sense I get from Arnie's response to this proposition is that since the hardware costs for Macs are obviously high compared with the cost of buying stripped down x86 boxes used for nothing but render farms, Newtek doesn't see much sense in pursuing an improved distributed rendering solution for the Mac. Am I wrong? I hope so, but that's what I took away from Arnies post.

But really, the need is there. And I'll explain why.

First, the Mac is still dominant in print publishing. Many of these design firms that specialize in print graphics have many many Macs in house. It would be really great if they could utilize these machines, after hours when most of the design staff has gone home, as rendering nodes.

As for the rendering client solution, Newtek really should take a look at (don't laugh) Bryce's Lightning. It's obviously not on par with Newteks rendering capabilities, but in terms of configurability and ease of use - it is unmatched. Using Lightning, you can set up many rendering nodes very easily, and it's extremely simple to understand. No manual needed. This needs to be the goal Newtek shoots for. A rendering client that can be set up and operated without cracking a manual and using a command line.

By Mike Stening (Mike_Stening) (213.235.9.84) on Friday, March 22, 2002 - 10:46 am:

i work for an ad agency and we have a few G4's whicch would be really handy to set up as a farm over the weekend or over night. cant see any reason not to do it, though i would be happier to get LW work correctly first before addinbg new features.

By Arnie (Arnie) (65.184.20.249) on Friday, March 22, 2002 - 10:53 am:

Yes Ted, you are wrong. My comment about cost was not relevent to NewTek's plans, it was just an observation about clusters. An improved distributed rendering system is important, but I do not think a cluster architecture, be it Mac, Linux, or Windows based is the answer. In fact, I think improving the ease-of-setup and documentation for screamernet would go a long way towards this goal.

By Ed Mag (Ed_M) (205.188.195.137) on Friday, March 22, 2002 - 04:59 pm:

[[[i would be happier to get LW work correctly first before adding new features. ]]]

Mike, let's try and push for this too. I believe with Dean Dauger's expert assistance, NewTek can have a superior farm/net solution. Your statement simply gives NewTek another *out* or excuse. They can always say... "The reason we haven't explored those areas yet is because we want to make sure Lightwave on the Mac is working properly" or something to that effect. I'm sure they can manage parallel project development.

-- Arnie, you state:

[[[Yes, Ted, you are wrong. My comment about cost was not relevent to NewTek's plans, it was just an observation about clusters. ]]]

Wouldn't it be worth while to be able to utilize the same machines that cost more as renderers too? Why couldn't there be a dual role? One could always say: "We didn't need to invest in additional Intel hardware (i.e., *render-only* boxes") "

[[[An improved distributed rendering system is important, but I do not think a cluster architecture, be it Mac, Linux, or Windows based is the answer.]]]

Why do you believe that?

[[[In fact, I think improving the ease-of-setup and documentation for screamernet would go a long way towards this goal. ]]]

Can anyone tell me exactly how ScreamerNet is built? How about the simple basic construction? How does it function on OSX? This is a rather strange beast and I'm sure others are wondering about it as well. Perhaps Ted Devlin can provide us with some insight. He seems to know the ins-and-outs of ScreamerNet fairly well. Anyway, Dean will be back from Canada soon and I'm sure he will have plenty to add.

--
Ed M.

By Ed Mag (Ed_M) (205.188.195.137) on Friday, March 22, 2002 - 05:02 pm:

Anyone on this forum have experience with or know anything about this:

http://www.edc.nl/ttn/hpc1.htm

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Friday, March 22, 2002 - 05:53 pm:

I already gave a longwinded opinion about why a cluster is not good for rendering. There may be something I'm missing, like a very fast method of accessing memory shared among TCP/IP connected machines. This is not relevant to why other macs in your office can't be rendering overnight, when their accountants are asleep. In fact the current LAN based LWSN is meant precisely for this, which is why, unlike many others, we include it free with lightwave. It is basically a version of LW without UI, that renders frames from scenes based on commands sent to it in the form of little 'job' files written to a directory shared by the LWSN node and the controlling computer.
Reading the link you posted, it sounds like basically the same thing as screamernet. They did not mention clusters, just a standard renderfarm with a browser based controller.

By Beam Tracer (Beamtracer) (198.142.219.71) on Friday, March 22, 2002 - 06:24 pm:

Accountants generally prefer Windows boxes. It's the creatives that prefer to use Macs!

By Arnie (Arnie) (65.184.20.249) on Friday, March 22, 2002 - 08:17 pm:

OK, so I meant really creative accountants, like Arthur Andersen!

By Beam Tracer (Beamtracer) (198.142.219.117) on Sunday, March 24, 2002 - 02:16 pm:

Those creatives don't want a Mac. They just need a shredder!

By Glen Hurd (Glenh) (141.158.235.206) on Sunday, March 24, 2002 - 09:19 pm:

Good one, Arnie ;)

By Dean Dauger (Dauger) (24.165.65.82) on Monday, March 25, 2002 - 01:15 pm:

Hi, I just got back from some presentations on Mac clustering at universities in the Montréal area, and the audience was enthusiastic about the idea of using Mac clustering technologies for major apps in addition to scientific purposes, so I'm very excited that a discussion has propped up here about using LightWave, or other apps, on Mac clusters. I thank Ed Mag for starting this snowball.

I'd like to address Arnie's skepticism. I think his comments are understandable, but it's been said before. Back in the early 80's, when the first parallel computers were being developed, most scientists doubted that a parallel computer could be used for scientific codes, even saying that most problems were impossible to run efficiently on a parallel machine. A scientist at Caltech named Dr. Geoffery Fox invited eight scientists from widely varying fields to help them parallelize their code and challege the skeptics.

Dr. Viktor Decyk was one of those eight scientists, and he had a plasma physics code. It turns out that all those codes ran quite well in parallel, flying in the face of the skeptics. They concluded that almost any problem of interest could be parallelized efficiently, only if you are sufficiently clever about how you partition the problem. They did not require complete rewrites.

Decyk was one of my advisors at UCLA Physics, and I keep in contact with him. I see a parallel (forgive the pun!) between the skepticism of twenty years ago in science and Arnie's skepticism now. Arnie is quite right to bring up these issues, but I think that they can be sufficiently addressed.

We can see the progress that's been made in scientific computing. By now, parallelization is not that unusual, and certainly does not require a ground-up rewrite, if you are clever enough. I would like to help LightWave become parallelized.

It's a matter of choosing your partitioning. I wouldn't want to parallelize at too low a level. I think it might be appropriate to parallelize so that individual processors are assigned one or many frames of an animation at a time, perhaps doing many minutes of work before communicating with other nodes.

I suggest using distributed-memory MPI because that's risen to the top as the fastest, most reliable, and most efficient way to parallelize code in scientific computing. In fact, some supercomputing centers (e.g., NERSC) is phasing out other parallel code APIs in favor of MPI.

MPI is implemented by Viktor Decyk in a code named MacMPI_X, which has been Carbonized and can be compiled by all the major compilers (gcc, Metrowerks, Project Builder, etc.). Pooch provides the support that makes the Mac cluster functional. Pooch for Mac clusters is something like the Mac OS and Finder for files and drives. And Pooch can be called and directed by other apps. (There are demos of that at: http://daugerresearch.com/) Our techniques are well tested and our approach has reliably produced results for our research and for others around the world.

A big reason why I think Mac clusters have a significant advantage over other clustering platforms is how you can reuse the hardware. Mac hardware and OS _do not_ need to be stripped down or even modified to be used in a Mac cluster. This means that the clustering features easily coexist with other apps. For example, in a test we did with 76 nodes at USC, we achieved floating-point performance well within the range of the largest clusters in the world, but the calculation was done on hardware not intended for clustering: an undergraduate Mac lab. We spent only a few days doing the tests and only added software. You may find out more info at: http://daugerresearch.com/fractaldemos/USCCluster/USCMacClusterBenchmark.html

My point is that there is a lot of untapped performance. That lab could be used at night when the students are away, but the admins need to know that the clustering features will not interfere with the students' work. I know others at Home and Garden network, the MGM Las Vegas hotels, and Sheridan college who would kill if they could combine their extra Macs to do large rendering or video editing jobs.

My recent background is physics, and I retain a part-time postdoc position at UCLA Physics in addition to running Dauger Research, Inc., but I'm also familiar with the Mac software industry. Have you heard of a product named Kai's Power Tools? It was a set of Photoshop filters, and I believe it achieved some fame in its day. I was one of the two programmers who wrote KPT versions 1 and 2 back in 1992-94, but I then left the company to pursue a doctorate in physics. In either context, I do like to see code run well and run fast.

In order to get more specific about how I might parallelize LightWave, I'd have to be more familiar with the technical specifics of the code. But the most effective parallelization philosophy I've learned is to choose your partitioning so that you minimize the amount of communication for the amount of computation you are doing. Just like figuring out how to code for any other type of problem, it's a matter of working out the details.

Thanks for your time,
Dean

By Arnie (Arnie) (66.88.8.234) on Monday, March 25, 2002 - 01:55 pm:

Cool to see you here Dean. Currently the Lightwave network rendering scheme partitions the rendering of animation so that each node works on whole frames, as you suggest. This method overcomes my criticisms by NOT requiring that memory be shared across nodes (my main concern).

On a finer scale, multi-processor nodes parallelize rendering of a single frame by carefully threading rendering operations, while sharing things like filtered texture caches and transformed geometry databases to minimize redundant storage and calculation.

Perhaps my issues are largely semantic, since I can't really see the difference between a LAN with nodes running the network rendering client, and a cluster. The rendering clients use a very simple protocol which only requires a shared directory, and uses the file system for all communication and data transfer. Thus it should already be prime for clustering. The main problems currently are the challenge of setting up disparate machines to have cooperating nodes. On the mac, this challenge is slighty enhanced by the awkward approach to command lines that mac apps are saddled with. Even this is not very different from using a batch script to launch a node with particular arguments, which is the preferred method for render nodes on other platforms.

By ted devlin (Eblue) (12.149.3.2) on Monday, March 25, 2002 - 02:26 pm:

" The rendering clients use a very simple protocol which only requires a shared directory, and uses the file system for all communication and data transfer. Thus it should already be prime for clustering. The main problems currently are the challenge of setting up disparate machines to have cooperating nodes. On the mac, this challenge is slighty enhanced by the awkward approach to command lines that mac apps are saddled with"

could be simpler arnie, don't share the directory, just have a reference on each node and controller to each possible node and controller (respectively). This is easier to setup, for the user and developer because of the Power of the Mac's New command line functionality.... UNIX. Which works very well in os X btw.

By Arnie (Arnie) (66.88.8.234) on Monday, March 25, 2002 - 03:26 pm:

"don't share the directory, just have a reference on each node and controller to each possible node and controller (respectively)."

No way would this be easier to set up. Adding a node would require editing something on every other system, and a shared directory for content and results would be required anyway.

By Ed Mag (Ed_M) (205.188.195.139) on Monday, March 25, 2002 - 06:30 pm:

In case anyone is interested, I found some URL's that touch on the idea of using clusters to address the rendering needs of 3D apps. It's nothing much though. Have a look:

http://www.cs.mtu.edu/new/html/abstracts/john_duff.html

http://supercomputing.swin.edu.au/

http://www-fp.mcs.anl.gov/collage/

http://www.workstationsuk.co.uk/tx-products-unix-beowulf.htm

http://www.computeruser.com/articles/1906,1,6,1,0601,00.html

http://www.sfi.ch/en/products/cluster.html

http://www.isi.edu/~cengiz/csci558/exercises/beowulf.html

------------------------------------------------
Project: AppleSeed

[[[Distributed computing is a system where many computers connected to a sparse network, typically the Internet, are each given a specific piece of a problem. It works very well for problems that can be cut up into completely independent pieces. For example, in the RC5 project, where the task is to break an encrypted message by trying one key at a time, testing one key does not depend on the result of any other key, or for 3D rendering, computing one pixel can be computed independently of any other. ]]]

Taken from here:

http://exodus.physics.ucla.edu/appleseed/appleseedfaq.html

--
Ed

By Arnie (Arnie) (65.184.20.249) on Monday, March 25, 2002 - 07:25 pm:

That statement about rendering in the appleseed exerpt is pretty silly. The time it takes to distribute all the content, transform/deform the geometry, filter the textures, etc would far outweigh the time it takes to then render a single pixel.

By Ed Mag (Ed_M) (205.188.200.165) on Tuesday, March 26, 2002 - 09:06 pm:

So I guess that NewTek won't even take Dean up on his offer, eh? Oh well, something good might have come from it. After all, It couldn't hurt to see his approach put into action though. Everyone on the forum including Dan seem really optimistic about it. It's clear to me that Mac customers are expecting more. Hmmmm... I wonder if Chris has spoken to Sanjay lately?

--
Ed

By Dean Dauger (Dauger) (24.165.65.82) on Tuesday, March 26, 2002 - 10:22 pm:

From the sound of your statements, Arnie, it sounds as if the main rendering engine in LightWave partitions the problem well enough. Based on what others have said, however, the mechanism to coordinate and control the nodes and data doesn't sound as robust. It's hard to tell for sure from reading what people have said, but that's what it seems like.

The parallel codes I'm familiar with usually coordinate work and exchange data between nodes directly with each other over the network, rather than through a shared file system or directory. The assumption of a shared file system is not portable across supercomptuing platforms and is not considered reliable enough for high-performance computing. (Most Mac clusters, unlike the typical Beowulf cluster, do not use NFS.) Using the peer-to-peer network between nodes, the coordination can be precisely controlled, if desired. Only in an unusual case (perhaps looking at different portions of a very large file) would shared file access be desirable. We only use command-line/batch-style on jobs that have nothing to do with each other, that is, that don't need any coordination, so using that approach to coordinate a single large task seems odd to me. But from the discussions I've read elsewhere on NewTek, it sounds like proper coordination is where LightWave is, well, disappointing people.

Again, I'm surmising this from the users' discussions, so it's difficult to say if that's the answer.

Dean

By Glen Hurd (Glenh) (63.140.21.134) on Wednesday, March 27, 2002 - 02:35 pm:

I used to have a 6-Mac render farm setup (previous job) and found that SN wasn't that big a deal -- the biggest pain was in typing all the little command line stuff on each machine before starting the rendering process; and then the pain was over. Once each machine starts rendering a frame, I don't see any advantage to Mac clustering versus anything else, since the CPUs are maxed out in each case. Or would the cluster models save us from problems with plugins that don't work with SN? Hmm, I bet each plugin would have to be rewritten to support clustering too (one more reason for PC programmers to dread the conversion to Mac). Wouldn't it be easier (and just as effective) to opt for a KPT interface in ScreamerNet ;)

By Dean Dauger (Dauger) (24.165.65.82) on Wednesday, March 27, 2002 - 03:05 pm:

I'd like to see a neat user-interface, but I'd like to see more than that too. Not only do I see the command-line approach as a major roadblock for most users to use a renderfarm or cluster, but I'd rather have the user not even fuss with being specific about how the job is partitioned or how the nodes are configured or what's installed.

There are some new things in Mac clustering technology that are available now. Imagine installing LightWave on only one node, then set up a large render job, and run it. LightWave then asks you, "I see that I'm connected to a cluster. Would you like me to use the entire cluster for your render job?" When you click yes, LightWave talks to the cluster, which then copies poritions of LightWave code and your data out to the nodes, which crunch on the numbers and return your completed job. You didn't have to be too specific on where the computations were being done, and you didn't have to install software specific to LightWave elsewhere on the cluster. You only had to use it on one node, then say yes.

That's a "Computing Grid"-like feature, and it's something that Mac clusters can do today. This works over the Internet too. Imagine being far away from a Mac cluster, and tapping into its resources: I've directed and seen the results of numerically intensive graphics and physics jobs from as far away as Münich, Germany, while the computations were performed 6000 miles away in a cluster at UCLA Physics.

We have the technology. It's a matter of fitting the pieces together.

Dean

By Ed Mag (Ed_M) (205.188.195.148) on Wednesday, March 27, 2002 - 05:32 pm:

Dean, I admire you enthusiasm and I think what you want to bring to the Mac community is fantastic! I hope NewTek is watching carefully, since this appears to be a significant discussion. Anyway, on the topic of clustering, I am curious about how AltiVec will be implemented *over* or *across* the cluster. Am I right in assuming that AltiVec optimizations will function the same over a cluster?

--
Ed

By age (Age) (210.49.160.213) on Thursday, March 28, 2002 - 05:26 am:

Sounds feasible to be.

Now imagine there is akind of a tracker window that you load up and it shows all the availble clusters that are close to you.

You load up the tracker and connect to say err the nearest university with a mac cluster.

Lightwave on the mac has been adopted more religiously than any other 3D app on any platform.
Newtek should use this momentum and aim for lightwave to be the app apple uses to show off its hardware at macworlds i.e LW becomes the photoshop of 3D.

I hope Newtek reads the passion displayed here from the mac community and thinks about some sort of apple seed app.

By Mike Stening (Mike_Stening) (213.235.9.84) on Thursday, March 28, 2002 - 06:31 am:

shouldnt we have the app itself working properly in OS X first?

By tim anderson (Tim) (24.31.96.61) on Thursday, March 28, 2002 - 08:43 am:

damn good point Mike....
Deans concept of the application
doing the "work" of finding available resources is wonderful. part of the problem with the current implementation is the comandline biz(ok , for you solderheads its a walk in the park
but for us creative types, its a nightmare, i spent half a day just tring to get the hub turned off, only to find i had a space in the wrong place...jeez)
however... with newteks bent towards total cross platform parity(ok... so they seem to belive it?)i can hardly imagine them devoting much time to something this "maccentric"
good luck?

By ted devlin (Eblue) (12.149.3.2) on Thursday, March 28, 2002 - 08:48 am:

"No way would this be easier to set up. Adding a node would require editing something on every other system, and a shared directory for content and results would be required anyway."

arnie, I'm not making a hardcore case for or against screamernet. These are things i want in my rendering network. Having said that, I think i have to address your post.

1. easier to setup? yes it would be, as well as easier to maintain. why? well at the current state of affairs, no matter who you are, if you want to network render you must have at least three sets of preferences for each machine, if you change the rendering controller, you have to change every node as well, or it doesn't work. SN is a fragile and tentative solution at best. Yes it works,sort of( well not for me, you see even though its setup properly on a 1 cpu farm, it still fails to finish renders, it stalls out, its un-reliable).

In my proposed system, yes, you have to go to each machine and set it up, but its one list, one set of preferences, and its easy to maintain, and it is highly flexible. on a node its a list of Possible render controllers, so that your node will acept renders from these machines, and on the controller, is a list of potential nodes (each system has a mutually exclusive list, such that one controller can have dedicated nodes, and shared nodes with another controller).
no shared preferences, no shared directories, no shared plug-in directories, no shared content folder, ie: no fragility. Why would this work? The controller computer can easily, ftp, copy, or move resources directly to the node, as needed, through the Render controller app itself. And since Any scene file "knows" where its resources are, your controller app can easily find the resources it needs to render the project.

So far all of This is painfully easy and apparent, for a mac programmer. http://www.cocoadevcentral.com/ (a beginners site for mac os X programming, one of my favs) hosts several articles on encapsulating Unix commands inside Mac OS X applications. All I am suggesting is a new way of applying tried and tested code.


2. "and a shared directory for content and results would be required anyway" ok I didn't build SN, I am unqualified to talk about SN in this regard. Fortunately I am not talking about SN, and I refuse to believe that a shared directory is "required".
I am a hobbiest programmer, and the things I have done, the things i have seen done in C, C++, Carbon, Cocoa, Applescript, all of them point to the fact that the mac at least has a whole lot of flexibilty when it comes to moving resources across a network. I have personally developed an app that translates an image (rgb - yuv) and then ftps it to a framestore device, in under 1 week of spare time, I have written my own file naming utilities in minutes that make use of the MV and CP Unix commands, I have made applescripts that easily move files from one machine to another, without so much as a hiccup. SN may need a shared directory, a pc may even need one (I doubt it, but i am willing to accept it, as I have no exp there), but the network rendering system, I want does not need a shared directory, for the simple fact that it is one of my requirements, and the technlogy is there. I am user, hear me roar, and all that.

any way, like i said before, its what i want in a network rendering system, not what i expect, not what I think Newtek should do, not what I think lines up with Newteks vision. Its pie in the sky stuff, if it was there I'd use it, but I won't use SN, and theres alot of people like me.

By Dennis Wilkins (Dennisw) (64.121.73.58) on Thursday, March 28, 2002 - 01:47 pm:

From Dean Dauger...
Imagine installing LightWave on only one node, then set up a large render job, and run it. LightWave then asks you, "I see that I'm connected to a cluster. Would you like me to use the entire cluster for your render job?" When you click yes, LightWave talks to the cluster, which then copies portions of LightWave code and your data out to the nodes, which crunch on the numbers and return your completed job.

All I can say is amen brother. I decided to go with LW over ElectricImage a couple years ago. A large part of my decision was based on Newtek having a 16 cpu mac render farm showing off stealthnet at Siggraph (I didn't actually go that year, but I sure saw the pretty pictures and read the hype). I figured that this showed a serious commitment to the mac platform and went with it.

Well, I don't know why Arnie seems to want to argue that screamernet works well enough for the most part – Why do you see posts daily if not hourly about problems setting it up? Why do you think there are so many controllers out that manage it and how many times people - pc users recommend them. Unfortunately, there is not a single one available for the mac (OS X) - and I've sent e-mails to every one saying that they are missing a BIG opportunity with no competition on the Mac platform and pleading with them to port to the mac.

I’m begging for a solution to this here, I don’t mind expending the effort in learning something that is necessary to my craft (I.E. Expressions, L-scripting, etc.) but to render something, I just want to hit a couple frickin buttons – I don’t want to waste my limited brain power on something that shouldn’t require any – that is the reason I use a mac. There are enough – plenty of things not working in Mac LW right now and this is an area that just needs to be fixed in my opinion.

I wonder if Dean could make a controller of his own without LW’s blessing - I have no idea if a developer has enough access to the type of info needed to do this sort of thing. I would buy something like this today - it’s just too bad that it seems LW requires so many different aftermarket plug-ins if you want to do something well. Compared to other apps I use LW sometimes feels like a whole bunch of plug-ins just stacked on top of each other – the extensibility is nice, but so is integration.

Sorry about the rant but I’ve been thinking about this for AWHILE (Siggraph 2000 was it?)

By Ed Mag (Ed_M) (152.163.201.82) on Thursday, March 28, 2002 - 03:08 pm:

Nice to see that people are highly supportive of what Dean wants to bring to the Mac version of Lightwave. However, I suspect that there is a LOT of backroom politics that need to be taken into account. I mean I wonder how much influence Micro$oft and Intel have with respect to what goes into LW? Hmmmm. Regardless of what companies might say, once you agree to be taken under M$'s wing, there is little chance of escape. In my opinion M$ is nothing more than a "pimp" that uses fear of retaliation to steer the market (even though they are in court for Christ's sake!) I mean that company has got some nuts!

Anyway, I said it earlier... NewTek has been given *another* chance to offer something of significance to the Mac community instead of scraps. The way I see it, Chris Cox is probably going to need more than 12 beers to help them iron out the problems in their code optimizations, but at least he offered (and remember, we'll know if they ever take Chris up on that offer, won't we? ;-)

Dean is offering basically the same thing. A vastly better cluster solution. I'm telling you all, we should start to e-mail the right people over at Apple and let them know how we feel. How long are we going to have to wait for substantial results? Seriously. I think NewTek is a great company with a lot of great things to offer the Mac community. We try being civil, we try to bring up intelligent discussion, yet it seems to fall on deaf ears. Someone here should e-mail the URL of this discussion to someone at Apple, no?

Hey, isn't Apple in the market for a 3D animation company too? I know they are doing an *eval* of the CAD/CAM market to see where the Mac can fit in, but I wonder what their plans are on the 3D animation front? Now that the LightWorks render engine is available for MacOS X. Apps like CATIA and Pro/E should be an easy port.

--
Ed.

By Arnie (Arnie) (66.88.8.234) on Thursday, March 28, 2002 - 04:10 pm:

Dean, I agree that a more friendly user interface for setting up the nodes would be a good thing. Indeed this is where most of the problem lies. There are 3rd party renderfarm controllers that do this better. Unfortunately we have had to prioritize this development against performance/stability/usability issues of the interactive application that impact a larger group of users. The issues in network rendering are platform independent, with PC users basically confronting identical difficulties in setup. Automatically installing LW and its plugins on any machine on the network would be a nice timesaver for people.
The decision for using the filesystem for communication is based on the simplicty and robustness of each node being able to write an 'ack' file that says "Waiting" or "rendering frame 237" and a controller writing a job file that says "render frame 893" or "Load r2D2_Flying.lws". This is a cross platform solution which is very easy for 3rd parties to use for creating controllers.
In addition, it is a requirement of most users that the finished frames accumulate in the same place, rather than being scattered among the nodes. Finally, the assets involved in rendering a scene can be quite large, and it just doesn't make sence to duplicate the object and texture files to every node, when they can simply be read from a common directory. This is especially true in the case of say, 8000 film-res background plates which would require many gigs of redundant storage on each node, when a given node may only need 1 or 2 of these images to render a given frame.
To suggest that LW development is leaned on by Micro$oft, or that some conspiracy against the mac exists is just zany.

By Arnie (Arnie) (66.88.8.234) on Thursday, March 28, 2002 - 04:16 pm:

Chris,
I haven't seen the CHUD toolkit, but I love the name.
I also want to take a moment to remember the thousands of anonymous CHUD who lost their lives, unsung, on sept. 11.

By Beam Tracer (Beamtracer) (198.142.205.61) on Thursday, March 28, 2002 - 04:21 pm:

Regarding Dennis's comment about Lightwave needing too many plug-ins... I think Lightwave actually requires less plug-ins than many of the other 3D apps around. 3DSmax requires many more add-ons than Lightwave to achieve the same functionality. I think you could say the same for Cinema 4D. By the way, Max & 4D both require you to buy each render-node separately, while with Lightwave each node is free.

OK... enough of defending Lightwave. I must question the Lightwave policy of keeping the features and interface standard across platforms. While it has its merits (a user can move between platforms and have no trouble using the interface) I think it also has many drawbacks.

By keeping everything the same across platforms, you avoid taking advantage of certain OS-level features that a platform may have. The renderfarm situation is a good example. It seems there are things that could be achieved with OS X in a different way than it could be done in Windows. However, taking advantage of such OS X features may mean that the interface and controls would have to be different from the Windows version.

I believe that most users of whatever platform would be very happy that their version of Lightwave was changed to take advantage of a particular OS feature. Not doing so may produce a lesser product.

By Ed Mag (Ed_M) (152.163.201.49) on Thursday, March 28, 2002 - 05:57 pm:

Good point Beam.... By keeping a largely "common" code base, you are missing out on a lot of platform specific features that could prove advantageous to users. What good is it if the hardware and Operating System offer features and abilities that will never be fully realized? I mean Jeezzus...

It seems to me that NewTek should be focussing more on platform specifics. Optimizations, base code, whatever it takes to make a "Mac" product or "Win" product for that matter; even if it means having the burden of developing 2 completely separate packages. After all, users are spending big $$. And I wonder what the likelihood is that their common code base is slightly x86 biased in some way. I'll have to ask around. In any event, it could explain why certain features aren't available or working properly on the Mac.

As for my comment about Micro$oft being a "pimp"... I stand by it. They have a great deal of clout and we all know that for developers, going after the Wintel market guarantees you a "cupie doll" every time... As for NewTek, I still think that they NEED to bring on some UNIX people (you know, MAC OS X and all) and hire some really skilled AltiVec programmers that reside "in-house"

Didn't Motorola lay off a bunch of people lately?? Anyway, you get my point. Then there is always the option of farming the work out to the OmniGroup. They certainly know OS X and Cocoa very well. Or even have Chris Cox do some freelance work for them. And Arnie, I really believe that NewTek should work with Dean on this one.

--
Ed

By Dennis Wilkins (Dennisw) (64.121.73.58) on Thursday, March 28, 2002 - 06:27 pm:

Just to clarify my statement, I wasn't just talking about added aftermarket plug-ins but the workflow in general. Modeler - Hub - Layout, weird interface glitches with spreadsheet and motion mixer, etc. What I meant is that the whole experience sometimes leaves me with a feeling of it being patched together (just my opinion - I'm sure other people feel differently - and I'm still learning).

I'm don't mean to bash LW - I try to promote it every opportunity I have (most of my friends are using Maya and Softimage). I've been a professional compositor for about 6 years, and I use a ton of plug-ins, but the applications themselves feel more unified.

Also, I don't have any experience with Max (not on Mac), very little with C4D, but why compare LW to anything else - I don't think Apple stays on top (IMHO) by saying - well, we're better than MS...

I don't think any company can be truly successful if all they do is stare into the headlights of their competitiors.

By Beam Tracer (Beamtracer) (198.142.217.44) on Friday, March 29, 2002 - 05:10 pm:

With regard to the assumption that Macs are no good for clustering because they are too expensive, let me quote a story from Newsfactor about PowerPC clusters:

"If power consumption and footprint (form factor) are not important, there are less expensive means of achieving the same performance"
"But we have found that most labs are now finding themselves constrained in space and suddenly aware of the cost of maintaining a cluster, which includes the electric bill for the systems and associated air conditioning.
"A NASA JPL lab was forced to spend US$15,000 on new electrical circuits and air conditioning due to a small, 32-node Pentium cluster. That would not be required if the system had been PowerPC, and that money could have been spent on more nodes,"
http://www.newsfactor.com/perl/story/17007.html

By Ed Mag (Ed_M) (205.188.195.157) on Friday, March 29, 2002 - 06:04 pm:

Hmmmm... someone mentioned that Alias|Wavefront is supposed to be making a big announcement at NAB. Does anyone have any idea as to what it might be? If it happens to be that Apple is acquiring A|W then we can probably kiss the Mac version of Lightwave good-bye... We already know hat Apple is looking to pick up a 3D company. I've spoken to a few of my contacts and they say that Apple is indeed evaluating the CAD market. This shouldn't surprise anyone...

It would be another instance of Apple having to take matters into their own hands. If Apple feels that developers aren't doing enough with respect to Mac support, then it is likely that they will end up seeking their own solutions; even if it means acquiring a company that doesn't even support the Mac at all. I wonder if Maya is in Steve Jobs cross-hair?

Anyway, back on the subject... Anyone have any ideas how we should handle NewTek's reluctance to the offers of assistance to develop a topnotch Mac product that's (at the VERY LEAST) on par with the windoze version?

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Friday, March 29, 2002 - 10:27 pm:

We will accept any help on improving lightwave on any platform. In fact, we now have a nice opportunity to hire up a bunch of the main engineering talent that were just cut from Maya's now closed development office.

By Beam Tracer (Beamtracer) (198.142.205.147) on Friday, March 29, 2002 - 11:41 pm:

Arnie, you could make a pitch to lure Wavefront co-founder Mark Sylvester, who apparently is leaving the company because he doesn't like the direction his company is going, and doesn't want to move to Toronto. If the guy at the top wants to bail out, there must be many more below him who want to do the same.

By Karl Hansson (Karl) (213.66.123.51) on Saturday, March 30, 2002 - 12:52 am:

I hope that even if apple is getting maya that it shouldnt cause Newtek to bail out of the mac market just because of the new competition. I have not used Maya and cannot comment on its "greatness" im sure it is but so far LW with all its plugins thats available is good enough for me.

Happy easter ya'll!!!

By Sam Easterling (Sam) (24.196.27.91) on Saturday, March 30, 2002 - 03:15 am:

I was told today that the announcement would probably be Maya 4.5. I was also told that the Mac version of Complete would be 4.5 as well. If this is true, that was fast dudes. This info came from my A/W reseller. Common sense would lead you to believe that if they didn't save the price cut for NAB, they would have to have something big to say. Who knows? If there is a buyout, I hope it is Apple, or atleast somebody who will keep OSX development on par with other platforms. Everyone I've talked to at A/W has overly stressed that Mac Maya is very important to A/W.

Considering Kerris was picked up by Apple, you would think they would be interested in Maya if they want a 3D package.

Ed as far as finding away to light a fire under Newtek, I think A/W just did that for us. Atleast I hope so. My migration to Maya by no means that I will no longer be using LW. I love Modeler and the renderer. There are some solutions available for integrating the two apps to some degree as well. I'm sure I'll be a little more reluctant to jump on the next paid upgrade right away though.

Arnie, it is interesting to hear that Newtek may pick up some new blood. From a users point of view it just seems like LW went into a tailspin after 6.5.

I don't think anybody needs to panic because of these price changes. It just means more choice of tools for the job for me. $1500-$2000 is CHEAP for these apps. Think about what you pay for some plugins by comparison.

By Karl Hansson (Karl) (213.66.123.51) on Saturday, March 30, 2002 - 08:46 am:

"It just means more choice of tools for the job for me." Amen to that! For the money that maya cost before I can spend on things like mocap-systems (Motion Capture). Hope the price of mocap-systems will go down as well.

By Arnie (Arnie) (65.184.20.249) on Saturday, March 30, 2002 - 11:00 am:

While A|W are spinning it as a move, it is rare that an ultimatum that causes the founder of the group to leave is really a move as much as a layoff. Maybe mark Sylvester is an expert coder who would benefit LW development efforts. I had heard than a number of Maya engineers were upset by the fact that the 4.0 release contained very little, but was rushed out the door to meet their service contract obligations. It may be that 4.5 is what they wanted 4 to be, or it may be the last real Maya release. If a company/product were going to be acquired, it would hardly sweeten the deal to gut your engineering team.
Sam, it is interesting to hear your opinion of LW after 6.5. It seems like that is not a majority opinion, because the 7.0 launch at last SIGGRAPH (with motion mixer, more powerful global illumination, a handy little taste of fur), and the subsequent 7b with P4 and Altivec optimized rendering were pretty popular. In a way the whole world went into a tailspin rcently.

By Sam Easterling (Sam) (24.196.27.91) on Saturday, March 30, 2002 - 03:02 pm:

Arnie, I started running 6.5b on OSX the day you guys posted it and ran until the day I received my 7 upgrade with 1 crash, and that was because I slipped up and edited an expression without turning it off first. By comparison 7b crashes several times a day. Performance in 7b is flakey as well. 6.5b was consistently smooth and stable. I think most users jumped to OSX with 7 and to them it was a huge improvement, they never experienced 6.5b on OSX.

The Altivec optimization was great, really the only reason I upgraded. A lot of us felt this should have been done to 6.5 however. I do like the global illumination as well. MotionMixer is cool and will get cooler. Mark Brown has some other cool stuff too. To me Sas Lite is an ad, I'm not sure I agree with you on that one.

Look at the list of features you named and count how many were purchased from outside sources. I understand that technology is purchased at times but I personally don't think Newtek is integrating it very well. As buggy as 7 is it makes you wonder how well things are being tested before they go out the door as well. And the recent plugin audit that was performed seems ridiculous. How in the world can Newtek not know at this point what plugins are functioning on what platform? After 6.5b ran so well and was such a huge step up for LW, I thought by now we would be seeing more improvement in the basic functionality of LWs animation and deformation toolset. I guess I'm disappointed as much as anything.

I'd rather praise LW and Newtek than complain. If I didn't have any interest in LW I wouldn't take the time to post on these forums. Myself and others have spent a lot of time on the mailing list and in forums such as these helping to support LW. I do appreciate your interest in this thread, though it has slipped off topic. I also hope Newtek is listening to its users and has some good stuff in store for us.

By Beam Tracer (Beamtracer) (198.142.205.151) on Saturday, March 30, 2002 - 06:01 pm:

Hi Sam. I agree with you. I've started another forum topic about the current Lightwave bugs and problems:
http://www.newtek.com/discus/messages/2/20730.html?1017532564

There are also many other threads about the pros and cons of Maya.

I'm hoping this thread can get back to the original topic of render farms and clusters with regard to Lightwave and the Mac. Please, everyone, keep this thread on the original topic.

By Dean Dauger (Dauger) (24.165.65.82) on Tuesday, April 02, 2002 - 11:54 am:

"I'm hoping this thread can get back to the original topic of render farms and clusters with regard to Lightwave and the Mac. Please, everyone, keep this thread on the original topic."

Hi again,

I appreciate everyone's comments on the current implementation. Arnie, I hope you could pass on the observations and suggestions here to the right people in NewTek, so that they can see for themselves that there is a demand for improvement. I think we can all agree that we want the best, most productive experience for the users.

If it becomes necessary to create a third-party way to improve renderfarm/mac cluster rendering for 3D apps (include those besides LW), I'm willing to take a crack at it. I believe the technical issues that Arnie raised can be addressed. Arnie, if you could give any tips or suggestions or APIs for how to link into LW, that would be much appreciated.

Thanks,
Dean

By Arnie (Arnie) (66.88.8.234) on Tuesday, April 02, 2002 - 01:17 pm:

An external (3rd party) render controller needs to write files like jobX (X is the node number) containing one of a few simple commands (init, wait, load [scene], render [start] [end] [step], and quit), and read corresponding ackX files from each node to get the status.

The hard part is installing and configuring the software on each node. This requires that the lwsn app be copied to each machine, along with the plugins, and that these be reconciled so that the config file used by the lwsn node points to the correct plugin path. This, IMHO, is where most of the stumbling arises. Standardizing node paths would make it easiest. Maybe this could be done using aliases.

By ted devlin (Eblue) (12.149.3.2) on Tuesday, April 02, 2002 - 01:37 pm:

arnie,
I implore you (newtek) to re-evaluate Screamernet.
as you said, the hard part is installing and configuring the software, and I insist that it is unnecessarily difficult.

Speaking for the mac side of things, there are dozens of creative solutions to this same problem, and none are as difficult as screamer net. these solutions (look at aftereffects for instance) were all designed before the advent of Os X.

X is a networking powerhouse, able to connect to almost any type of network, natively : smb, nfs, appletalk, afs, novell is coming, etc..., and it has quite a few tools for connecting to network devices such as unix comand line tools, shells, and applescript (which can send commands without writing out a file... across networks and operating systems).

apple has developer tools and documentation for network borne apps (web objects), and a very clear and concise api for networking, which is based on industry standards.

there are more than enough tools to allow for a clean, easy to use, network rendering system.

aliases are bandaids, for this problem.
re-write screamer net so that installation and configuration, is impossible to screw up, for example:
to create a render node... the user copies the application to the new node, and launches it.
maybe the user then has to tell the node what ip address to listen to, but its not necessary.


thats the fix, anything less is a patch, and will bring you back to this point, in the near future.

By Michael Wolf (Lightwolf) (212.9.168.87) on Tuesday, April 02, 2002 - 04:29 pm:

Well, on the PC-side (sorry..) I use an easy setup.
Since all of our jobs are stored on a UNC File name base (i.e. \Server\Content\LightWaveJob\ as an example content dir), we keep our screamer nodes installed on one central place on the server, including all plugins. Even my local config points to the plugins on the server, so if I install a new plugin, I dump it on the server, add it on my local machine and copy my lwext.cfg to the server where all nodes look for it. While we use Spider, this works with all LW network controllers and is quite simple to handle.

Oh, you can even install Lightwave on a central storage space on your server if you want to. Just merge the content of all your licenses into one file and your set (you might want to use the -c command line to establish user-based local prefs though). Come to think of it, on windows one could even store the configs on a user base across the network with something like "Layout.exe -c\server\LWInstall\%Username\" or so. Something to check out.

Sorry to be a bit off topic on the Mac Forum.

Cheers,

Mike

By age (Age) (210.49.160.213) on Tuesday, April 02, 2002 - 09:07 pm:

new RENDERMAN is out, what does that mean for us osx users?

By Ed Mag (Ed_M) (152.163.201.83) on Tuesday, April 02, 2002 - 09:56 pm:

This is what I snagged off of the Web...

[[[RenderMall Alpha.1 for MacOS X
Posted on Sunday, January 13 @ 19:29:12 EST
Topic: MacOS X

RenderMall is the first renderer independent RenderMan Interface implementation. This makes it easy to write 3D applications on-top of the familiar Ri calls without limiting the application to a particular renderer. Such an application can take advantage of any RenderMan renderer as long as this renderer implements the renderer plug-in interface defined by RenderMall. Conversely, a RenderMall plug-in renderer can work with any application as long as it is implemented on top of the RenderMall framework.

Note: This version is of alpha quality and may only be of interest to developers. A number of things are not fully implemented yet or are not completely tested. I.e. the 'Preview Renderer' is currently only accessible from the Cocoa application environment but not Carbon. The complete package contains:

The RenderMall.framework which provides a renderer independent implementation of Pixar's RenderMan Interface Specification v3.2/3.1 together with many additional APIs for working with multiple contexts, plug-in renderers, resources and shaders.
A 'Preview Renderer' plug-in renderer which is based on OpenGL for real-time display of RIB data/files.

A 'RIBViewer' application for viewing multiple RIB files at once.
The 'ribcat' and 'ribinfo' CLI tools. The RenderMall framework gives application developers a number of additional APIs over the standard Ri calls:
The context manager allows the easy construction and management of multiple RI contexts. Contexts may be created for the sole purpose of reading/writing ASCII and binary RIB files but also for the purpose of rendering a 3D scene to a Cocoa NSView, a Carbon GrafPort, an off-screen area or just full-screen.

The renderer manager allows an application to enumerate all plug-in renderers available at a host, inquire its capabilities, specific attributes, options or shaders. It also makes the life of renderer plug-in writers easier by offering default implementations for tasks like parsing RIB files, declaration management or default implementations of the various standard procedurals.

The resource manager provides a way for applications to define memory based resources like RIB archives, images or shaders. It also gives a renderer plug-in writer tools at its hand to make the creation, discovering and processing of both disk- and memory-based resources simpler.

The shader manager may be used by applications to find out the actual type of a shader, how many arguments a shader has or what the exact declaration of each shader argument is. RenderMall is distributed as open source and free software under a BSD style license. It can be found at

http://homepage.mac.com/dietmarplanitzer/FileSharing1.html.

RenderMan is a registered trademark of Pixar ]]]

I grabbed that from here:

http://macmegasite.com/modules.php?name=News&file=article&sid=53

Renderman press release:

http://corporate.pixar.com/news/20020402-75908.cfm

--
Ed M.

By Beam Tracer (Beamtracer) (198.142.217.211) on Wednesday, April 03, 2002 - 04:57 am:

Killing off the OS9 version of Lightwave as soon as possible will help Arnie and the other programmers concentrate on the "networking powerhouse" of OS X, that Ted mentions.

By kent (Kent_M) (63.203.70.97) on Wednesday, April 03, 2002 - 07:40 am:

Hi,

Our shop uses an 'inhouse' app to mange render jobs over our mac network. It does this by turning every computer that it's launched on into a render slave that recognizes and loads render jobs from various apps placed in central location.

When launched, this app periodically checks ("watches") a shared disk for render jobs, and starts the necessary apps to render them as they become available, in LW's case this is SN. There is no central administration module - machines can be added or removed from the pool at any time without disrupting other machines.

To render something requires only that the scene and elements be on a disk that is accessible to the network, and that an alias to the scene is placed in a central folder. When each artist goes home at night they simply start the node app on their machine and everything is handled invisibly.

LW SN is used to do the rendering but is invisible to everyone. It works well but has simply become the 'backend' of the set up. Commandlines are set automatically by the render controller apps. Segmenting of the render jobs into chunks is controlled by the render controller apps. Relevant plug-ins are copied as needed, updates are handle automatically.

best,
Kent

By Paul Goodrich (Pdg) (66.114.244.132) on Wednesday, April 03, 2002 - 07:43 pm:

Kent,
Where can we buy/get this?
Paul Goodrich

By kent (Kent_M) (63.203.70.97) on Wednesday, April 03, 2002 - 11:43 pm:

Hello,

Unfortunatly you can't. Sorry. It's a system cooked up by a couple folks at our company and implemented by our in-house programmer.

However, as I understand it the concepts are fairly straight forward, and I mention it here because it proves that the kind of rendering system that people want is not so out of reach (I think this is what people are talking about, basically), and can be built on top of the current system.

I'll talk to our people to see how much of the basic concepts I can talk about without getting the grown-ups excited and post back.

~Kent

By Arne Kaupang (Arnek) (217.70.229.51) on Thursday, April 04, 2002 - 02:35 am:

Kent, your company could make money selling this app commercially. I'd sure buy it on the spot (if the price was reasonable).

Arne Kaupang

By ted devlin (Eblue) (12.149.3.2) on Thursday, April 04, 2002 - 09:14 am:

beam,
killing the os 9 version may make it easier to build a better screamer net. But its really not necessary.

I think that approaching the problem a little differently is called for.

Screamernet, is essentially the LW renderer with a minimalistic command line system bolted onto it. On the mac, 9 and X the command line runs through a command line emulation (not really the appropriate word) application, called SOUIX, which btw is a very good thing for os 9. this is all fairly seamless to the user, there are a few problems with the interface, but most of them come from incomplete implementation of the app.
I mean you should never ever be directed to Force quit an application as a SOP. but, none of that enters into my major gripe...
Screamernet, is very difficult to setup, and maintain. it is good that there is a small command list that Screamernet responds to, a large list might make it more confusing. the fact that it relies on a shared directory is suspect (in my mind). And the fact that control is limited, and there is no error proofing, indicates to me that Screamernet isn't a complete implementation of a network rendering system.
Kents system sounds wonderful, and it makes screamernet sound good too, but whomever designed that system agree with me... Screamernet isn't a complete system.

so now, armed with my opinions and whatever information/ misinformation informs them, what can be done? Well like kent, we can apply a band aid to screamernet, there are quite a few to choose from and any one of us could possibly write one of our own, Screamernet is after all a pretty good rendering engine that takes arguements in the form of a file, but I would prefer a more central solution.

Newtek owns Screamernet, they can simply tear out the command system, and recompile the renderer as a Lib or a dll, or a bundle. It would then take its commands at a lower level, now with this valuable intellectual property, you can do any number of things, like build an application the includes the renderer, and utilizes the native networking capabilities of whatever platform its on, to Just work. And the great part about that is, you protect the renderer, and you make it flexible. Newtek could then experiment with the way the network rendering engine networks, without worrying about how it renders. You simply cannot do that right now, because of the way screamernet was concieved. It relies on having its own plug-in folder, it relies on having a direct connection to the data, it relies on any number of pref files, and it relies on job and ack files.
this is a bad situation, it hobbles Screamernet, and makes it as fragile as my 85 year old grandmother. One thing out of place, kills it, and it doesn't take that very well.

if you reconcieve Screamernet, and really look at whats become available since screamernet was designed, i don't care what platform you are on, you'll see tools that may be harder to code, but easier for the user. A render node, could easily be designed so that it doesn't need anything but the address of its controller, and the controller can seamlessly send whatever data is needed for the render, Just look closely at kent's post, isn't that exactly what his system does?

I don't really think Newtek is ready to slag screamernet, but i want to them to be open to some ideas when they are ready:
moving data instead of files (commands, and render data),
1 central (software)renderer per machine for network and Lw rendering,
flexibility and robustness is key,
1 preference file, no more.
so far, Newtek has not figured out easy (thats easy for the user),
easy = flexible = good = marketshare = good for newteks bottom line.

and what do i get for all of this free advice?
quite possibly the opportunity to part with my hard earned money, and thats all i want. Good product for my money.

By Ed Mag (Ed_M) (205.188.200.31) on Saturday, April 06, 2002 - 05:23 pm:

Hi guys, Dean asked me to post a message telling interested parties to e-mail him with ideas and discussion. Ted, I'm sure you have plenty of ideas cooking. Why don't you e-mail Dean for some collaboration. It's pretty clear to every Lightwave user on this forum that ScreamerNet needs to be scrapped. I mean it sounds like it's cobbled together. Besides, it seems that a superior implementation can be developed. Please, everyone e-mail Dean if you are interested. He will be happy to listen to your ideas. The important thing is that we keep this discussion going.

--
Ed

By Dean Dauger (Dauger) (24.165.65.82) on Monday, April 08, 2002 - 01:01 pm:

Hi, I like the concept and description that Kent is suggesting here. I can understand how his shop wouldn't be interested in reselling its in-house solution, but I think we can all welcome the ideas it suggests. I'd have to poke around with LW to see if I could adapt it to the flexibility that users would need. I'm willing to collaborate to see it happen.

In any case, Ed is correct that I'm interested in ideas, suggestions, etc., along these lines. Better to have more ideas than less, I'd say. If you'd like to discuss ideas about parallel computing and Mac clustering not specific to LightWave, there is a mail list for this purpose at: http://daugerresearch.com/mailing-list/ As we can see, there is reluctance for some app developers to pursue this approach, and I think that is an issue that needs to be addressed. Perhaps a "grass-roots" movement is necessary.

Thanks, Dean

By Arne Kaupang (Arnek) (217.70.229.39) on Friday, April 12, 2002 - 04:39 pm:

I'll sure sign up on that "grass-root movement". This is just too an important issue to ignore by NewTek. People have been complaining about the stoneage non-user-friendly Screamernet since day one.

The two years I've been using Lightwave I've got the impression that NewTek really listen to their users, and add a lot of features that are being requested. So I'm really kind of blown away by the reluctance to start thinking new regarding Screamernet.

I've wasted numerous hours trying to set up Screamernet properly, and never getting it to work the way I need - and most other Lightwavers say the same. Bring Screamernet into the 21st century. Now! Make setting up multiple-node rendering in Lightwave as easy as the push of a button.

I've been working as an Art Director and graphic designer for several years, and there is a term I've used a lot through the years that I feel is appropriate here: "Kill your darlings". Sometimes your best ideas aren't the best at all. Throw 'em away and start thinking new.

And pretty pleeease listen to guys like Dean Dauger who is generous enough to offer you assistance and bring out new ideas and ways of thinking that will benefit the entire Lightwave community.

It doesn't matter how much I love the look of the renderer, if I spend more time trying to get proper output than designing, modeling and animating... Time is money, and it is such a waste spending time on rendering setups when you can spend it on more profitable things - like animating.

I appreciate all the work and tears you guys at NewTek have put into a wonderful product as Lightwave, but the 3D scene is getting tougher and the competition harder every day. It time to listen to the community.

Please.

Thank you for your attention,
Arne Kaupang

By Karl Hansson (Karl) (217.208.3.35) on Saturday, April 13, 2002 - 12:23 am:

Ad my name to that grass-root list.

By Ed Mag (Ed_M) (152.163.201.66) on Saturday, April 13, 2002 - 02:57 pm:

I suggest that anyone seriously interested in bringing a great clustering approach to rendering and harnessing the power that a cluster of Macs offers should take the time to e-mail Dean Dauger and let him know explicitly what you'd like to see happen. Ask questions and get involved. Dean LOVES the discussion of ideas and features. He's very flexible. His e-mail address was posted several times in various posts on this topic. One other thing we should keep in mind. That is -- Dean's experience with clustering and is approach needn't be specific to Lightwave. I decided to bring up the idea here because I really like NewTek and feel that they have great potential. Similarly, the Lightwave users (Mac) that post to the forum seem to exhibit a genuine interest in the Mac platform as well as Lightwave in general. Dean and I figured it would be a perfect place to get something started. Dean is eager to work directly with any company interested in nurturing this already *awesome* technology on the Mac platform via commercial / professional software packages. Hey, if NewTek isn't interested, Perhaps Alias|Wavefront is... Someone should get something started on other Mac message boards relating to a particular vendor or their wares. From the sound of this entire discussion, NewTek seems to be only interested bringing wares that are "good enough" to the Mac. When the heck is NewTek going to get COMPLETE PARITY between the Pee-See and Mac versions?? And this "Duo" thing doesn't seem to be the answer. What's needed is a code base that is more "platform specific". having. If you think about it, the code needs to be somewhat "closer to the metal" to gain the advantages each platform has to offer. At least better optimizations with respect to AltiVec. Chris Cox has already spoken on that matter. Anyway, well see, Keep the posts going and keep the questions headed in Dean's direction. He'll field them as he gets them. Maybe even post a few to this particular form so we can all get involved.

Best

--
Ed M.

By Beam Tracer (Beamtracer) (210.50.30.6) on Saturday, April 13, 2002 - 06:50 pm:

While it's preferable that Lightwave for Mac and Windows both have feature parity, I think it would be a good thing if either version had unique features based on a particular OS advantage. The clustering discussion highlights the fact that the Mac OS may have some unique features that should be taken advantage of.

It's also interesting to know that many Mac Lighwavers are using network rendering, despite some suggestions that the Mac hardware is too expensive for this. The fact that some are developing their own in-house rendering software means that there is some improvements that can be made to Screamernet.

Maybe Dean could make some money by creating a powerful easy-to-use clustering solution for Lightwave.

By Ed Mag (Ed_M) (152.163.201.194) on Sunday, April 14, 2002 - 08:14 am:

Beam writes:

[[[While it's preferable that Lightwave for Mac and Windows both have feature parity, I think it would be a good thing if either version had unique features based on a particular OS advantage. ]]]

Hmmm. I wonder what those advantages would be?

[[[The clustering discussion highlights the fact that the Mac OS may have some unique features that should be taken advantage of. ]]]

Agreed. Dean is certain that he can bring a superior solution to Lightwave, but I suspect that Mac OS would have such an advantage that a Widows implementation of it would be impossible (maybe) Only Dean can tell us that, but fro the sound of it, his implementation already obliterates LINUX-based x86 clustering as well as Windows-based. Then of course there would be thousands of WinDroids droning out, demanding that that feature be available on Windows with equal performance. Here is where the politics come in.... NewTek might have to cripple the Mac implementation in order for it to function more like the PC version. This is NOT desirable. The trouble is that most houses want "cheap" hardware (or so they believe it is due to the initial costs). Kinda reminds me of Bic / Papermate pens and paper / plastic dinnerware. All those tools are dirt cheap, but start to add them up over time and the cost far exceeds that of a nice pen that has a good feel or a ceramic / glass set of dinnerware. I know, it's a crude example, but you get the point. Regardless, this is exactly what I believe is going on with ScreamerNet... The Mac version with Dean's implementation would probably offer a dramatic increase, but then we'd have to wonder if NewTek coders would be putting enough effort into it. Dean would have to work *directly* with them to ensure the highest possible performance. Likewise, he would then explain to the Mac users where the limitations would be.

[[[It's also interesting to know that many Mac Lighwavers are using network rendering, despite some suggestions that the Mac hardware is too expensive for this. ]]]

I think this is such a stupid argument... Ask almost ANY professional in and field. For example, a carpenter may have a particular Hammer. A fisherman might have a preferred rod and reel, etc., etc. Mechanics aren't using the cheap soft-metal versions of hand-tools; they are using Snap-On, MAC, Craftsman et al. The point is not many of those craftsman are using the "cheapest" tools available and I suspect that digital craftsman won't mind shelling out the extra bucks to get a better quality product either. Anyway, the "Macs are more expensive" argument is tainted. It's bogus. My cousin is already on his 3rd computer in the last 4 years. He's going for a 4th! the HP Kayak system (Win2KPro) that he's currently using is just too buggy as were al the others, ones that he built with the best components available at the time. However, he openly desires to transition to Mac OS X. The only trouble is that he needs to be able to use AutoCAD and SolidWorks and they aren't available on the Mac (We can thank the M$ monopoly for this) So again, people usually have an innate tendency to stick with what they are familiar with and so on...


[[[The fact that some are developing their own in-house rendering software means that there is some improvements that can be made to Screamernet. ]]]

Completely agree. ScreamerNet needs to be axed.

[[[Maybe Dean could make some money by creating a powerful easy-to-use clustering solution for Lightwave. ]]]

For best possible performance, he would have to work directly with NewTek engineers. This is where I'm a bit weary of NewTek's reluctance. Let's face it... They can develop a solution using Dean's approach (with Dean) and then decide to use it or not. The point is that they can at least explore the possibility and develop something so they can compare it to what they already have. The trouble is that this "feature" might not be available on the PC and then the influence from those "outside forces" would be at it again... If you know what I mean. Bottom line? NewTek need to put much more effort into the Mac version. They can start by listening to their Mac customers. They can also take Chris Cox and Dean Dauger up on their MOST GENEROUS offers. At the same time, they can hire a few UNIX/PPC people and one or two AltiVec specialists. If the latter is out of the question due to "cost" then they might want to farm their optimizations out to Chris exclusively or contact the OmniGroup for assistance. The fact is that we all agree that NewTek needs to start doing something and soon.

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Sunday, April 14, 2002 - 10:39 am:

The rendermanager that ILM created uses screamernet, or, more specifically uses the LWSN render-only application. They have replaced the role of the Network Render panel in layout with an application that can control multiple rendering and compositing applications used by their pipeline.
So far, there is nothing I have heard that is Mac specific to the clustering technology, except that, being mac-based, it is far easier to set up than its Linux sibling. Indeed, Dean and everyone else has yet to indicate concrete reasons why a cluster is so much better than regular LAN connections for network rendering. Many of the claims are based on incomplete understanding of the network rendering process and requirements, or on simple advantages of some automated setup, which don't actually AFAIK require a clustering architecture so much as some clever install scripts.
Adding such scripts would be welcome, and relatively straightforward. It may be that Dean's Muster system already incorporates this. While LWSN is both robust and flexible, 2 often conflicting requirements, the means of installing and controlling it could surely be improved upon. That is the goal of the stealthnet and rain utilities, which seem to have grown a bit too ambitious for their own good.

By Dean Dauger (Dauger) (24.165.65.82) on Monday, April 15, 2002 - 11:36 am:

Hi Arnie,

I believe there is something more to this clustering approach. Much more.

Let me make an analogy with flight. Why do we remember the Wright brothers? If you define an airplane as simply a fixed body with wings, then the earliest airplanes that carried people were developed in Europe years before the Wright brothers' flight. Using that definition, you might see no reason why the Wright brothers' airplane is interesting.

However, one of the things that makes the Wrights' invention unique is the design and implementation of control surfaces on the airplane. The ability to control the aircraft was essential for creating a practical, reliable airplane, and is a major reason why we still remember the Wright brothers.

So, if you consider the technology we are proposing to be little more than a bunch of processors connected via a network, than I can understand why you don't see any difference between this and "regular LAN connections".

I believe one of the most relevant advantages here is the level of _control_ over the cluster that the Pooch application provides. (In order to provide that control, Pooch acquires the needed information, mechanisms for implementing that control, etc.) By working with Pooch, an application can make intelligent decisions over where the work is going for the purpose of making computing in parallel (such as for network rendering) hassle-free for the user.

There are always exceptions, but, after reading these posts (which seem inconsistent with your claims of robustness), it seems many users find that SN doesn't provide the needed level of control and reliability. That's a reason why ILM and others felt there was a need for a better solution.

My above description is the first advantage I could think of; there are more, even some we may discover if LW were implemented to use this approach. If you still do not understand, then perhaps you have to see it for yourself. Please download the demo Pooch from: http://daugerresearch.com/pooch/ Once you install Pooch on a few nodes in your network, then launch the AltiVec Fractal Carbon demo and select "Automatically Launch onto Four Nodes" from the Parallel menu. With one click, the computations will then be performed in parallel rather than on one node. I'd like to see every numerically-intensive app, "out of the box", run in parallel that easily.

Thanks for your attention,
Dean

By Arnie (Arnie) (66.88.8.234) on Monday, April 15, 2002 - 01:02 pm:

A fractal is perfect for parallel computation, since its work relies on a tiny amount of input data in comparison to the results, every pixel is independent of the other pixels, and the momory requirements are virtually non-existant. In addition, the calculated pixel result can be returned via message to some controller. None of these benefits apply to real-world 3D rendering. The handful of complaints in this thread are based on users' struggles to set up the network and nodes correctly. I sympathize with this, but their problems could be solved with better documentation and some simple scripts/utilities. ILM's in-house network controller was not made because LWSN was inadequate, indeed, it relies on LWSN. Rather it is a long-standing part of their workflow which controls numerous applications including LWSN. It probably significantly predates the adoption of LightWave into their pipeline.
I do not mean to sound hostile to your offers to help, or to claim that LWSN is perfect and easy, but I have yet to be convinced that their is some better alternative being proposed here. Many of the less-informed suggestions are not really practical. For example, the suggestion that a shared directory is a problem, rather than a simplifying benefit, is grievously misguided. Paranoid speculations about some hidden forces which prevent Mac functionality from competing with PC functionality are a regular source of amusement for the LW engineers, and can only be made by someone who has never tried to set up a network on a PC.
What pooch needs to do for LW users, ultimately, is to install and configure LWSN correctly on their nodes. Doing this would solve 95% of the problems users experience.

By Beam Tracer (Beamtracer) (210.50.30.3) on Monday, April 15, 2002 - 03:46 pm:

I acknowledge that both Arnie and Dean have immense experience in their respective fields of programming... more than a humble user like myself. At the same time, I don't feel my assumptions about PC vs Mac functionality were paranoid, either.

Rather than comparing PC and Mac, I could have made the same point comparing Mac OS9 and OS X. Lightwave features have remained essentially the same between the two Mac OSs. My comments are more enthusiasm than parania, asking "now we are on OS X, what exciting features of this OS could Lightwave take advantage of? What could Lightwave achieve in OS X that couldn't be achieved in OS9?"

Anyway... the discussion is very interesting, nonetheless. Let it continue!

By Arnie (Arnie) (66.88.8.234) on Monday, April 15, 2002 - 05:20 pm:

Good questions Beam T, and some answers would be unlimited memory/virtual memory, as opposed to fixed RAM limits determined before you run the app and multi-processor acceleration of OpenGL to name two. Having a stable, industrial strength OS would seem to be a major boon to all apps. I love OSX, but I am not sure what other exciting OS features there are to take advantage of... Of course LW works with the dock... woohoo! Try that on windows or OS9 ;}

Also, Mac conspiracy theorists should take a gander at the experiences of WindowsXP users with 7.0b.

By Ed Mag (Ed_M) (205.188.195.200) on Monday, April 15, 2002 - 05:44 pm:

Here is a thought, How about NewTek provide Dean with the necessary material so he can whip something together as an example. Seems simple enough to me. Any code that exchanges hands can be protected via some kind of NDA. You see, here we are at a roadblock. Dean's approach cannot be tested because NewTek won't allow him the necessary access to the information that he requires. NewTek is dismissing a claim on the basis of what is known as *speculation*. NewTek is having it's beliefs challenged. Dean is assuring all of us that there can be a much better alternative to ScreamerNet. Ted Devlin offers substantial evidence as to why it should be scrapped in favor of something more natural or native to OS X. Again, as long as NewTek is reluctant we all loose out. Like anything else, times change. the way thing are done change as well. Most people are afraid of change. I think this is a prime example. It is simple really. If Dean's approach proves to be a failure then NewTek has lost nothing. They can still provide users with a cobbled-together approach to network-rendering o the Mac. It's time we stop dragging around a dead horse. I'm being serious here people. Dean's offer is genuine. What company in their right mind would turn down an offer to improve their products? Not only that, but Dean didn't even mention that he would ask for reimbursement for his efforts. I propose that NewTek take Dean up on his offer and if it fails, then nothing is lost. The R&D is free this time. However, if the gains are significant than further discussions should be considered, but for cry'n out loud don't look a gift-horse in the mouth! Dean believes it can be done; why not let him have a shot at making it happen?

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Monday, April 15, 2002 - 08:58 pm:

Dean's approach could certainly be subjected to thought experiments, as has happened here. It is not a religious matter. I know one can drive a nail with a wrench, but the wrench does not persuade me to throw away my hammer.

Ted has admitted that his opinions are misinformed, which I can verify. This is a far cry from "substantial evidence". While some "more native" solution might make you feel more special, it is not clear what benefits it would offer, or even what it would consist in. Even assuming we wanted to give up on the possibility of multi-platform renderfarms. I am ready to be convinced by any reasonable, detailed suggestions. None have actually been presented. Ted is suspicious of a shared directory but has suggested no substitute. The idea that textures, bkg images, meshes, etc. can somehow be better shared with messages than a file system requires some knowledgeable justification, and is not even a solution to any real problems. Nodes knowing a controller address is not a solution, and does not relieve nodes of the burden of being configured to find their own plugins.

There is no big secret being withheld. All Dean should need, which is documented somehwere in the free, publicly available SDK, is the following protocol description:

After "init" is placed in a job file, LWSN will put
"Initializing" on the first line of the ack file and the machine
type (x86, PowerMac, SGI, Sun, Alpha, MIPS, or Itanium) on the
second line. Then the controller puts "wait" in the job file and
LWSN responds with "Ready" (the same pair that follows a load or a
render).

The "load " command is responded to with "Loading" in
the ack file.

The "output " command is responded to
with "Setting output file options" in the ack file.

The "content " command is responded to with
"Setting content directory" in the ack file.

The "status " command is responded to with "Ready" on
the first line and the same serial number on the second line. This
is for verifying that the LWSN machine is still alive and ready
(since a plain "Ready" in the ack file might be left over from a
previous time).

The "query" command is responded to with the scene filename in the ack
file.

The "render" command is responded to with various progress report
messages.

During rendering, the "abort" command can be sent, and LWSN will
respond with "Aborting render". Also, the response to the "status"
command is a little different, for example "Rendering frame 34
(80% done)". The serial number argument to "status" must be
different than the previous instance of that command (to prevent LWSN
from spending all its time responding to an old command sitting in the
job file).

By Ed Mag (Ed_M) (64.12.105.173) on Tuesday, April 16, 2002 - 05:09 am:

[[[I know one can drive a nail with a wrench, but the wrench does not persuade me to throw away my hammer.]]]

Well, that all depends on the type of hammer and if it is really nails that you are trying to drive in. The point is that it is quite possible that you've been holding onto an outdated method or using the wrong method from the start. Furthermore, there is a chance that Dean is simply offering a better way to drive that nail. To be honest though, I think you hit it squarely on the head... When the only tool NewTek has is a hammer, everything looks like a nail... You should at least give it a try though. What can it hurt?

[[[Dean's approach could certainly be subjected to thought experiments ]]]

You're never going to know for sure with "thought experiments". That's completely ridiculous. It falls under speculation. If you can't test it in actual, real world use then you will never really know. Arnie, your comments are seeming more and more like the old belief that the world is *flat* and you'll be damned if anyone is going to change your [opinion]. Perhaps it's time for a sabbatical?

--
Ed M.

By tim anderson (Tim) (24.31.96.61) on Tuesday, April 16, 2002 - 06:59 am:

as a casual observer of this conversation,Arnies reluctantance could be, because no one
has addressed his simple question of why a cluster based solution would be faster than a LAN based? he has admitted that the current implementation has issues.

could /would New tek provide some simple scripts/utilities for LW users, ultimately, to install and configure LWSN correctly on their nodes? if Doing this would solve 95% of the problems users experience, it would seem to have some merit, if for no other reason than to free newteks support staff,from having to deal with the "handful " of idiots like myself=)

the fact that Arnie has participated here shows he is open minded, and asking for substantiation
of claims is not un reasonable(IMO). Get Mr. Dauger what he needs and lets see if its really faster
and most of all easy. i for one would be more than happy to pay for results.

Ed, there is an old saying here in the south.... you will catch more flys with sugar, than Schit.
your shots at Arnie are not gonna get us anywhere.

By Arnie (Arnie) (65.184.20.249) on Tuesday, April 16, 2002 - 08:12 am:

Thank you Tim, for clarifying my point. I am not offended by Ed's passionate yet uninformed positions. It so happens that in the development of software, as opposed to the psychological disciplines that Ed seems most familiar with, thought experiments are completely valid, and often called design. While it is quite common for 'design' to encounter unanticipated problems, it is extraordinarily rare for designs that don't work 'on paper' to actually work when implemented.
Computer's are pretty well understood, so it is not like there is room for new discoveries from failed experiments

Casting my simple, pragmatic questions as some sort of blinders is patently absurd to anyone with development experience. If fact, I think it is Ed's blind insistence that everything is broken, and that everyone is conspiring against his platform that seems irrational, and based on blind faith.

What is the harm in letting Dean make a better system? None. It is free and easy, and he could probably sell it. All the information is available, and others have done the same. In fact, Dean could probably ally with the Lightnet folks, or Tequila Scream, or Spider, or one of the exsiting renderfarm controllers, to get a head start, and save hours of R&D time. I am ready to answer any questions, as is probably overly evident.

A sabbatical would be nice, but then who would stand up for logic and technical accuracy?

By Michael Wolf (Lightwolf) (62.158.34.60) on Tuesday, April 16, 2002 - 10:00 am:

Hi there,

I've been following this thread for some time, and I have a couple of comments (I hope I can, even though I'm a PC user ).

From my experience, Network rendering with LW is quite easy to set up ! once you know how to do it !. We're using Spider on PC's, and our network is set up in such a way that it takes me around 30 minutes to add a naked machine to the renderfarm (this includes installing the OS !), installing spider and prepping LWSN is a mater of a mouse click.

I assume this is a bit different on the mac side of things, and the fact that we have a centralized server seems to make this quite easy.

There are some nice network rendering solutions out there though, and I hope that Newtek will sometime release a version of StealthNet that works...

Looking over some fences, here is stuff I'd like to see:
Web based interface (Cinema 4D), with thumbs of all rendered frames.
Distribution of single frame renders across network nodes (Real 4D), especially for the dreaded F9 preview renders, may be even a distributed Viper...

While the Web based interface can be solved by third parties, the second request can't (since it involves smart cacheing of geometry and textures, direct links from LW to a render controller which in turn controls all the LWSN apps...) etc.

I think that the hardest part is the engineering of that revamped LWSN part, making it cross platform is (relatively) easy. And I'd prefer a LW native "clustering" solution to stacking it on top of something else.

However, since LWSN isn't really much more than a remote controlled batch renderer currently, I don't see the point of talking about clustering. And Arnies points are all valid. Remember that "Render across the internet" feature in Stealthnet ? Think 1.2 MB per rendered frame (PAL D1), and then tell me where to get the kind of bandwidth that makes up for the savings in rendering time.

Just my 2 euro cents,

Mike

By ted devlin (Eblue) (12.149.3.2) on Tuesday, April 16, 2002 - 10:19 am:

i have weighed in here, in this, discussion, as a user. As such, I do not need proof or some sort of offering to convince the programmer that his job can be done.

I am here to point out what, in my humble opinion is a confusing, half-hearted program design.

the theme i have been pushing, is that regardless of how screamernet is implemented (clusters, etc...) I would not use it, unless it was rendered easy to use. I am a user, that is my prerogative. I have offered vague and airy suggestions on what I think "Easy" is. Again, my prerogative. I do not believe making a render controller controller, is an appropriate answer. saa.

I am not pushing a platform specific solution, I am not in any way accusing Newtek of back door policies.
I believe that newtek is looking for better-enough. Better-enough is a term I heard first when I was reading about OS x's networking subsystem. Apple had a choice between two systems, the one in os 9 which is based on some really good technology, and the one from Nextstep, which is an industry standard, and mature, and already mostly implemented. Apple chose the mature, industry standard, because although the system in os 9 is better, its not better-enough to offset industry compliance and ease of development.

I can live with better-enough. I use lightwave and will continue to do so for the immediate future. My suggestions are meant to get you the programmer interested in alternative solutions that you may not know about, or have not considered, because, I feel that screamernet is dead weight, and there is no "fixing" it.

Arnie, I like to think that my ideas are great, but thats not really important. whats important is that: Screamernet is dangerously close to not-good-enough, it is a strike against an otherwise fine package. I am a consumer and will compare screamernet however unfairly, as i see fit (its fair bc I use the same yardstick against every other package as well). Screamernet does not need to be a boat anchor, it could be nice looking, and easy to setup and use, with very little effort, in comparison to the total effort exerted by users worldwide to get SN running and maintained, including the building of render controller controllers, isolated networks, diligent reading of the ongoing theories about getting sn to run and keeping it running, and generally pulling out hair.

I still hold that 95% of all the problems with SN are program design problems, not configuration problems. Whats the difference? the second one blames the user, the other puts the responsibility of fixing the problem square on the shoulders of the developer.

By Dean Dauger (Dauger) (24.165.65.82) on Tuesday, April 16, 2002 - 10:37 am:

Hi Arnie,

For the record, I first wanted to correct a potentially inaccurate impression:

>> A fractal is perfect for parallel computation, .... None of these benefits apply to real-world 3D rendering.

Just to be clear, this type of parallel computer doesn't just run fractals, and it's not the only parallel code I've written. As you can see by running the cluster, that's an app that is well integrated with the cluster. If you would like other examples of parallel codes that perform well on such clusters, please see:

http://exodus.physics.ucla.edu/appleseed/science.html
http://exodus.physics.ucla.edu/appleseed/appleseedsites.html

or my dissertation: http://dauger.com/DaugerDissertation.pdf

These are scientific codes, not packaged into an app, that are owned by those scientists (so I can't post those codes). Their demands on the cluster are much greater than the Fractal demo of course. But if you talk to the researchers themselves they can tell you how much they have benefited, how well their codes ran, and how much work they got done because there was so little fuss dealing with the mechanics of the getting it to work. Also, although its focus is more on advantages over Linux, there's more in an IEEE paper:

http://www.daugerresearch.com/pooch/PnPParallelComputing_Dauger.pdf

To be honest, Arnie, I don't know what kind of answer you want to hear. I'm getting the impression that the only way to convince you is if I already wrote the entire solution for you.

>>All Dean should need, which is documented somehwere in the free, publicly available SDK

Could you tell me where that SDK (with any related documention) is? The Mac version, if available?

>>What is the harm in letting Dean make a better system? None. It is free and easy, and he could probably sell it.

Maybe that's just what I'll do.

Thanks for the info,
Dean

By Arnie (Arnie) (66.88.8.234) on Tuesday, April 16, 2002 - 04:01 pm:

OK Dean, I am definitely not a clustering expert, but my understanding is that it is very similar, in terms of architecture requirements, to multithreaded processing. The main difference is that the 'threads' are running on different machines connected via LAN. My main concern with this in the context of LW 3D rendering is that there is a potentially huge amount of data that must be shared by the different threads. On one machine, this can be shared in RAM, given sufficient handshaking. Over a network, this data will have to traverse the net and be cached locally, and/or it will have to be recalculated redundantly by each 'thread'. This is why I have doubts about breaking the render process into finer granularity than one frame per node.
The function of the shared directory in all this is to be the repository for the gigs of data required by each node. Since most calculations are only valid for 1 frame duration, breaking the process at one frame per node does not force multiple nodes to duplicate the mesh deformation, texture calculations, illumination, etc. performed by another node. Calculations remain redundant in the case of still textures, static deformed meshes, and other special cases.
The answer I want to hear is "what advantage in this process is provided by a cluster?"

Look for the sdk under Lightwave3d.com. I may have a more detailed document than the protocol pasted above somewhere also, I will try to dig it up, but ultimately it is as simple as it seems.

Ted, configuration problems are not necessarily the fault of they user, they are caused by lack of good configuration utilities, documentation, etc.
Michael Wolf can set up his nodes very quickly, because he knows how. The process is not much different on macs, (just puttng the command line options in a icon shortcut vs. a text file). It is definitely a NewTek shortcoming that the setup is not easier. There should be a node installer. I have been working on a nice little commandline file generator using OSX supercool project builder. The development priority has definitely been on other, more broadly useful features than network rendering, I admit. It is just that the proposed solutions here just largely miss the mark.

By Ed Mag (Ed_M) (152.163.201.62) on Tuesday, April 16, 2002 - 05:12 pm:

A few things to comment on:

Tim -

[[[as a casual observer of this conversation, Arnies reluctantance could be, because no one has addressed his simple question of why a cluster based solution would be faster than a LAN based? ]]]

Wouldn't it be easier to test the approach to see exactly what the results will be? Sheesh! We can all speculate and make educated guesses, assuming something will or will not work. An *explanation* as you put it comes across as a sales pitch. Dean already said he will attempt to prove it if given the chance. So, let's forget about explanations as to *why*, Let's instead see if in fact it can be done.

[[[the fact that Arnie has participated here shows he is open minded, and asking for substantiation of claims is not un reasonable(IMO). ]]]

Tim, you are misplacing the burden of proof. Either way, It's Arnie's responsibility to address it no matter how you look at it. Dean said it can be done (or at least attempted). Arnie said it's pointless and there will be no significant benefit. Dean can't *prove* his remarks unless Arnie is willing to give Dean what Dean needs in order to test the claim. As for the logic, the burden of proof lies with Arnie, not Dean.

In a nutshell, Arnie is arguing:

"Just as I said Dean, you can't even provide an answer as to why a cluster based solution would be faster than a LAN based with respect to Lightwave
, much less any other substantial evidence. . It's clear Dean that you really don't know how we implement rendering across a LAN using ScreamerNet. I've explained to you why your approach wouldn't be better than what we already have with ScreamerNet. Please, Dean, show me the substantial evidence proving that I'm wrong. "

This is called shifting the burden of proof. It's that simple. A tricky tactic that many casual observers won't pick up on. Sometimes people that commit this fallacy don't even realize that they are committing it. Fortunately, I'm not just a casual observer; rather I'm a motivated user that want's to start seeing results instead of excuses from companies that people pay good, hard earned $$ for. In any case the burden of proof lies with Arnie and NewTek.

So far EVERY SINGLE USER that has posted here wants something better than what's being offered. They want Lightwave and not some other software package. They also want NewTek to listen to what the paying customer wants. Mac users want a "Mac solution". Not a generic solution.

[[[While some "more native" solution might make you feel more special, it is not clear what benefits it would offer, or even what it would consist in. ]]]

Spoken like a true PC user. Forget that something might actually be *better*, Let's just stick with 95% of what the rest of collective is doing. Sheesh! Oh, and Tim, please refrain from attempting to shift off topic into a Mac vs. PC discussion...

[[[Ed, there is an old saying here in the south.... you will catch more flys with sugar, than Schit. ]]]

That's a fine saying, Tim.

[[[your shots at Arnie are not gonna get us anywhere. ]]]

I'm not taking shots at Arnie at all and I'm not trying to be a jerk. In fact, I like Arnie. I like NewTek. I wouldn't be here if I didn't. All the pleads from Mac users over the years are taking soooo long to even be acknowledged that it seems that it's falling on deaf ears. Someone needed to give them a jolt. Sometime talking nice only gets you a few bones. That's bad when you already paid for the steak. So, here we have it, up front, here and now. Not ONE generous offer, but TWO! Let's not forget that Photoshop 7 is complete and shipping. I'll bet Chris Cox is looking forward to those beers ;-)
------------------------------------------------------------------------------------------

Arnie -

[[[Even assuming we wanted to give up on the possibility of multi-platform renderfarms. ]]]

Someone PLEASE tell me what advantage multiplatform renderfarms have. Someone should correct me if I'm wrong, but from my understanding, most shops are either one or the other etc... But that's not really the point. This whole concept of an amalgamated renderfarm appears nobel on the surface, but it sounds more like a marketing ploy than an actual benefit. As a matter of fact, having universal code that ignores the specifics and unique qualities of the *metal* only seems to make life easier for the programmer and doesn't necessarily mean that because it makes it easier it is therefor better.

[[[Casting my simple, pragmatic questions as some sort of blinders is patently absurd to anyone with development experience. ]]]

Then give the people who genuinely want to help you improve your wares a shot at it. Don't dismiss them as misunderstanding.

[[[If fact, I think it is Ed's blind insistence that everything is broken, and that everyone is conspiring against his platform that seems irrational, and based on blind faith. ]]]

Oh boy, You're not gonna like this, but the simple truth is I spend most of my time sitting behind a black junk-box that has "Compaq Presario" silk-screened across the front of the case. The only Macs I use are from those people whom I've set up with personal computer systems (sister and best friend included). I'll be getting my own Mac shortly. For now I only use my PC to brows the web. That's it, nothing else. When I need to get something done I go and find a Mac.

[[[A sabbatical would be nice, but then who would stand up for logic and technical accuracy? ]]]

Logic? Technical accuracy? Please don't tell me that you are *that* sure of yourself. I'm not that sure of what I would like to see, but at least I'll give it a shot and try and make something happen or at least get a discussion going. As for logic.. you haven't been *that* logical or reasonable at all. Let's look at a bunch of the fallacies that you've been committing since the beginning:

- Untestability (argument to the future): the verity or accuracy of the evidence, premise, or conclusion, cannot currently, (or perhaps ever as it would seem here in this discussion) be tested. Until we let Dean do what he has to do, saying that it won't work because someone *believes* it won't work without even testing it (especially when an offer was previously made) is a fallacy and therefore not logical.

- Ad hoc hypothesis: hypothesis used to explain away facts that seem to refute one's theory.

All Arnie has been doing in this discussion is explain away what Dean is trying to offer. Hmmmmm...

-- Lip service: verbal agreement unsupported in action or true conviction.

Yep, this is what I understand this to be what a lot of Mac Lightwavers believe is happening. It would seem that Mac lightwavers have tried the *sugar* rout. It's not exactly working.

- Shifting the burden of proof: demanding that the person denying and assertion prove his/her case, whereas the burden of proof is upon the person who argues the position.

That on I explained to Tim earlier.

- Apriorism: attempting to deduce facts from abstractions and principles rather than inducing from facts.

This is where Arnie mentions his "thought experiments"... Let's forget that and get onto testing Dean's approach and producing some results that will be factual.

- Rationalization: making excuses instead of addressing the issue.

This seems to be the BIGGEST problem that Mac users have with NewTek. Anyone reading the discussion can grasp that. With that, we can add:

- Nothing but objections: continually raising objections as a means of avoiding the issue.

- Fallacy of opposition: those who disagree with you must be wrong and not thinking straight.

Note Arnies statements about Ted and myself or anyone else for that matter.We all don't seem to be "thinking straight".

-- Genetic fallacy or poisoning the well: the source of, or supposed motivation behind, the idea determines its worth.

This one is probably aimed at me. Somehow my wanting Lightwave to be a superior product on the Mac and wanting something better than ScreamerNet, but not having the advanced technical insight to the inner workings of SN or LW somehow makes my idea of bringing clustering to the Mac and LW irrational. Possibly because I'm simply a *blind* Mac user..

-- Multiple questions or assertions: asking a complex question or a series of questions, or stating a complex assertion or multiple assertions, while only allowing for a single simple response, and then assuming the oppositions inability to adequately respond is indication that their position is wrong.

This is what I believe most people see here. Arnie is asking for proof from Dean, but Dean needs the materials that only Arnie has to even make an attempt. Even when Dean tries to explain the advantages, his position is incorrect because he can't produce any substantial evidence.

Anyway, the point is, NewTek should at least work with Dean to see if anything better can be reached. And Arnie, I'm NOT taking shots at you OR NewTek. Like I said, I wouldn't even bother wasting the bandwidth by being here.
--------------------------------------------------------------------------------------------------------------------------

Michael Wolf -


[[[I think that the hardest part is the engineering of that revamped LWSN part, making it cross platform is (relatively) easy. And I'd prefer a LW native "clustering" solution to stacking it on top of something else. ]]]

Why, I'm getting the impression that any network rendering should be independent of the main app. What makes that sort of *integration* any better than an external solution? Certainly can't be ease of use and configuration. How about less finicky? Less fragile?

Anyway, I have a few other ideas / leads to follow up on. I'll keep you posted if anything interesting comes from them.

Best

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Tuesday, April 16, 2002 - 07:09 pm:

Ed, I am glad to hear that our heated debate, featuring my criticism of your and others knowledge, is not offending you personally. That is definitely not my intent, and I value your sincere and passionate desire to see a better Lightwave. In fact I share that intent.
An important part of my job, in working on LW development is prioritizing the many possible development directions. Without this, everyone would suffer. A critical part of prioritizing development is an estimation of feasibility, and some calculus of cost vs. benefit. To make these decisions, one must carefully think through the requirements and likely problems for a given task. This is a general requirement for any rational development. This is the reason why a thought experiment is important.

This editor is a pain, so rather than tackling your laundry list of smart sounding, obfuscatory "logical fallacies", let me shoot down a handful of the most absurd of your 'claims':

>Wouldn't it be easier to test the approach to see exactly what the results will be?

Would it be easier to build a car with wheels on top than make a sketch and run it by a mechanic?

The answer is NO. Developing a whole system is not nearly as easy as looking at the fundamental constraints. We can determine on this forum, given enough posts between Dean and myself, what is possible, what is impossible, and what remains indeterminate. I'm sorry of you want to slag a rational approach to development as if it were a rhetorical trick from a lawyer. I'm sure Dean can see through this drivel, especially now that I have rephrased my simple question with a detailed picture of the assumptions that inform my concerns. If he tells me that there is a large, fast shared-memory mechanism among nodes in a cluster, that would resolve many of my concerns.

>So far EVERY SINGLE USER that has posted here wants something better than what's being offered.

Obviously everyone wants something better. I do.
The topic heading and inflammatory, misleading posts give naive readers the impression that there really is something better that is being ignored. This may be true, but we have no idea what it is. Semi-coherent rants judging psychological motivation, rather than hashing through technical problems only obscure important communication.

> Apriorism: attempting to deduce facts from abstractions and principles rather than inducing from facts.

Logical deduction is a perfectly valid approach to take. Induction only really works in mathematics, elsewhere it is statistical at best. I can see that someone who has a weak grasp of the relevant abstract principles would shy away from them, but abstraction is at the heart of software engineering.

Fallacy of opposition: those who disagree with you must be wrong and not thinking straight.

>Note Arnies statements about Ted and myself or anyone else for that matter.
>We all don't seem to be "thinking straight".

You may be thinking straight, just without any actual knowledge of your topic.


> Multiple questions or assertions: asking a complex ...[blah blah..], while only allowing for a single simple response..

Amusing that this claim would buried among a page worth of responses to multiple assertions in multiple posts. Whatever I am doing to only allow one response is surely failing. This format basically requires that multiple questions be piled into one message. Why is that bad? Your victim mantle is not fitting so well.

>Arnie is asking for proof from Dean, but Dean needs the materials that only Arnie has to even make an attempt.
>Even when Dean tries to explain the advantages, his position is incorrect because he can't produce any substantial evidence.

Complete bull. Dean needs nothing to answer my questions but perhaps some clarification. Saying he can only "Prove" his point by doing it is, as I have demonstrated, ridiculous. he has nothing to prove anyway. It would just help for him to clarify what benefits would result from a cluster based architecture, just as plausibility arguments.

>Anyway, the point is, NewTek should at least work with Dean

I regard this as a very public way of working with Dean. He has been dragged into the center of this, but has been willing to participate in our mutual exchange of knowledge from our separate areas of expertise.

>Why, I'm getting the impression that any network rendering should be independent of the main app.

The idea behind an independent network render app (LWSN) is to generate CPU intensive results on machines that don't have expensive display hardware, and to lower the memory requirements of those nodes by not including unneeded UI code.

By Arnie (Arnie) (65.184.20.249) on Tuesday, April 16, 2002 - 07:51 pm:

http://www.LiquidDreamSolutions.com/
Has a Mac OSX client in beta for their butterfly net render render controller. They are soliciting testers.

By Beam Tracer (Beamtracer) (210.50.30.6) on Wednesday, April 17, 2002 - 07:05 am:

ButterflyNetRender looks very interesting. The testimonials section on their website implies that Jimmy Neutron was rendered with it.

By tim anderson (Tim) (24.31.96.61) on Wednesday, April 17, 2002 - 08:39 am:

ED,

[[[While some "more native" solution might make you feel more special, it is not clear what benefits it would offer, or even what it would consist in. ]]]

Spoken like a true PC user. Forget that something might actually be *better*, Let's just stick with 95% of what the rest of collective is doing. Sheesh! Oh, and Tim, please
refrain from attempting to shift off topic into a Mac vs. PC
discussion...]]]

i did not say this...., if you would calm down enough to see through the rabid foam you are generating you might have noticed this?????????????????? for the record i own 3
macs, (8600/300,/g4500,DP800) 0 pc's. i dont even care about a pc......as you would say "sheesh". ....instead you were too busy manipulating an objective post with
"Outhouse psychology", which seems to be your specialty. talk about shifting off topic. spare us, please!

in the future, if you are going to use quotes from other post, at least show the courtesy of attributing them correctly....

and let me make sure on this one because i am still shaking my head here in disbelief.......you do not even own a mac?
Pardon me, i am noted for being a bit slow sometimes, but how does one become a mac LW user, without a mac?
this is a truly strange place....

your pal
tim

By Beam Tracer (Beamtracer) (210.50.30.6) on Wednesday, April 17, 2002 - 09:05 am:

Take some deep slow breaths and then we can all calm down and get back to the topic.

I don't know how ButterflyNetRender works, or how it differs from Screamernet or Deans solution, but it's good to see some choices coming to the Mac at last. OS X seems to be attracting many developers.

By Ed Mag (Ed_M) (152.163.201.72) on Wednesday, April 17, 2002 - 10:43 am:

OK, here is an interesting e-mail I received from a chat-buddy of mine, John C. Welch. Many of you might know John as one of the contributing columnists from MacWEEK. He's a networking specialist on many platforms. I decided to post his comments here on this discussion board. If you have any questions or thoughts I can either forward them to him or perhaps I could get him involved in the discussion (that is if people are interested in his thoughts on this topic). Either way, here is what he writes:

[[[So here's my thoughts, after lurking for quite some time, take them as you
will. I also apologize for any mistakes I make, as there is a dearth of tech
docs on ScreamerNet.

First, multiplatform does not imply, nor require a single code base.
Microsoft showed just how bad that idea is. You can have separate, tuned
coded bases for different platforms that all communicate together properly.
In fact, this is the better way to do it, as you can still share code when
possible without causing any one platform to take a performance or stability
hit.

There are two areas that are going to bottleneck a render farm, no matter
how you do it, the network, and the nodes.


On the network:
First of all, there is no practical way apply SSE/AltiVec to network ops. So
any thoughts on that is just silly. I couldn't find any comparative studies
on throughput for SN in various situations, so it's hard to tell how well SN
uses available bandwidth. (although if anyone wants to hook me up to test
it, I'll happily do so, measuring network throughput is easy.)

As far as bandwidth usage goes, if you're doing this, and trying to limit
how much bandwidth SN takes, that's silly. From what I understand, SN uses
fairly constant communication during rendering across a network. So you want
the biggest bandwidth available. If you are able to use gigabit, do so, you
can actually get a full gig off of it, even with Ethernet's 20% overhead.

If this network conversation is as continuous as it seems to be, then you
also want to make sure that your network infrastructure is clean. Bad
networks are easy to build, hard to troubleshoot, and will make things run
really bad, and make it look like it's bad for all the wrong reasons.

Now, as far as SN goes, is it using BSD sockets under Mac OS X, or the OT
shims? If the latter, that should be changed, you're getting an overhead hit
there, around 5-10%. You could also implement a protocol NKE, and intercept
the packets at the kernel boundary, so as to speed up processing, but you'd
want a clear indication that you will get a significant performance increase
before doing this. You might also want to look at the buffer sizes you are
using. From the FS overview at WWDC '01, it was clear that Mac OS X works
better with fewer larger read/writes than with more smaller ones. Don't poll
the connection, that just mucks everything up performance - wise. With Mac
OS X, you have a limited set of hardware to deal with, so you can tune
better for that hardware.

I'm also not sure, since we are talking about a shared directory, what file
protocol ScreamerNet uses. There are a lot to choose from, and again,
without seeing some test data, (and NewTek must have done these tests,
otherwise, how do you logically pick a protocol), it's hard to say which one
to use. I definitely think you want to make your connections at as low a
level as possible. "Connect to Server" would be a bad way to go here.

On the end nodes:
This is the other bottleneck, and there are some things that can be done to
help out here. For one, factoring the application so you have a background
faceless kernel that does computations independently of the UI. That would
almost allow you to run it as a daemon, and render without having the
machine logged in. If you write the kernel as a BSD application, you avoid a
lot of UI overhead. This also makes AppleScript implementations much easier.

Another advantage to this factorization is the fact that you can heavily
optimize this for a specific platform, without creating completely distinct
codebases. In most products, the UI code is bigger than the engine.
Factoring the interface allows you to push common UI code, and platform -
specific kernel code.

Since LightWave is Carbon, then you are taking it in the shorts in the UI
anyway, as with the 10.1.X versions, Aqua in Carbon is neither thread-safe
nor reentrant, so you can't thread the UI any better than you can in 9, but
at least that's only within your process. This will get better, but it's not
going to be a quick fix. Again, factoring the interface from the engine
avoids this, and gives you more flexibility in distributed rendering
implementations.

Anyway, just some thoughts on this whole thing.

john
--
"Death waits in the dark."
US Army Task Force 160 "Night Stalkers" ]]] - John C. Welch


Just thought that some people might be interested. And regardless of what others on this board think, I'm sincerely interested in Mac users getting the most for their money. Just look at all the other discussion topics. How many are actually praising NewTek for the more than adequate effort they are putting into their Mac products? The more common ones are all about complaints and bugs and performance issues. Sorry if I opened a can of worms here, but my interest is in seeing customers interests served; at least with respect to software they have heavily invested in.

---
Ed M.

By Julian Johnson (Julianjohnson) (158.152.33.115) on Wednesday, April 17, 2002 - 12:53 pm:

Ed - Surely Newtek's position on the Mac platform can't be defined by Arnie's questioning of the cost/benefits and overall viability of clustering and an apparent unwillingness to let an Adobe programmer investigate the Lightwave source? (However much we'd like to see Chris get stuck in there!). Nor should it be characterised by the posts on these forums which, by their nature, carry a lot of feedback from users at the point when they find bugs and/or performance issues. (What 3D app doesn't have 'performance' issues or bugs of some sort?). It's faintly hubristic, too, to claim that the majority of Mac users are dissatisfied, that the codebase is poorly optimised; that ScreamerNet, as it stands, is hopeless and to conclude that Newtek should be rightfully chided for 'slacking' on the Mac side on the basis of all this 'evidence'.

There's a much broader context within which this debate should be seen - one which acknowledges Newtek's history on the Mac and one which accommodates all the other priority developments that Mac users want.

Newtek was the first company to bring a high end 3D application to both the Macintosh back in 1997(?) and to OSX last year. Of the big four - Newtek, Alias, Discreet and Softimage - Newtek has by far the smallest programming team and support infrastructure and yet, unlike the others, has chosen to develop for this period across a wide variety of platforms - Alpha, Intel, OS9 and OSX.

It's obvious from Arnie's posts that resource is incredibly tight and that all efforts have to be prioritised rigidly. In such a context, is it very surprising that the extent of mac-centricity you demand is not immediately forthcoming? or that a willingess to go out on a limb to experiment with Mac clustering is not embraced wholeheartedly?

There's a danger that this whole debate is only polarising views and serving to erect boundaries and create paranoia where there should be none. There is absolutely no question that Newtek are committed to the Mac platform and that its developers are pro-Mac and, particularly, OSX. The very same arguments about developing platform-specific optimisations and enhancements occur from PC users who are also 'compromised' by Newtek's cross-platform stance.

Listen to this pro-Mac stuff from Brad Peebler over at Postforum a week or so ago:

"Matt Craig is/was the LW Mac programmer that was mentioned and he is TEARING it up on the new version. The code that he is creating now is the most Mac integrated he has ever created. The Mac version never looked so good".

Whilst I'd love to see a revised GUI for Screamernet that took all of the complexity out of the process, I can't help thinking that I simply know too little about the Mac Lightwave market to understand just how many users would benefit and what other projects would have to be jettisoned. What is the typical Mac Lightwave setup - small one-man freelancer, small multi-disciplined studio, medium-sized 3D outfit etc? How many are looking for a more sophisticated render controller and how many just want to get Screamernet to work?

For my part, if there's a toss up between developing a feature like a node based surface editing paradigm where individual maps can be 'shared' across multiple surfaces and surface attributes, say, and a clustering capability I would vote for the former every time even though it's not Mac-specific.

The debate about clustering should be placed within the wider discussion of what future developments we want to see happen to Lightwave Mac and what are the overall priorities for Mac users. These discussions need to be tempered by some cognisance of what a small development team can achieve across multiple platforms at the price LW is purveyed.

Given the strictures of this context, instead of sharpening your blade on Arnie's exposition of Newtek's current position, might it not be more constructive to take the debate on to where clustering fits in to the overall picture for Mac users - to find out just how big the potential market is for Dean's hard work; to find out how much of the problem is related to the interface for Screamernet rather than the underlying technology and to clarify where other much-needed developments and fixes sit from a Mac perspective?

In that vein, and as an example, here are my top-of-the-head priorities and wishes:

1. Bugs fixed - UV Maps, Tesselation Spheres, Broken Plugins, Full Plugin Set
2. Wider application of multiple group operations in Layout (beyond Spreadsheet) 3. Faster antialiasing
4. Faster OGL in Modeler and better support/architecture for high poly objects 5. Node based Surface Editor for sharing attributes across multiple surfaces
6. Deeper integration for Viper
7. More intuitive GUI for Motion Designer, PFX and more realtime previews overall
8. An XSI-style stack paradigm where an object and it's history are embedded so that you can go back in the tree and manipulate stuff - a combination of, say, Illustrator's non-destructive Effects and Photoshop's History
9. A more intuitive bone construction and setup interface.

I could go on :-) but the point is that, however clunky, the existing Screamernet setup does the job I need it to do - I'd rather Arnie worked on any of the above in preference. The fact that there are several companies developing network rendering solutions with OSX clients only adds more weight to the argument that says Newtek should concentrate elsewhere.

It's too facile to characterise these responses by Arnie as negative or dismissive when, in fact, they're lucid and cogent explanations of why Newtek isn't yet convinced about the benefits of clustering. To then move on and inculcate some sense of grievance because it looks like Newtek are ignoring vociferous Mac users seems a little misguided and unfair. I may have a completely skewed set of priorities from the 'average' Mac user, but it seems wrong to castigate Newtek so forcefully for not yet picking up on this one idea and to impute to them a stance on the Macintosh that their track record shows is not valid.

Another few Euros cast into the pot.

Julian The Mac Lightwave Resource Page http://www.exchangefs.co.uk/lightwave/index.htm

By Arnie (Arnie) (65.184.20.249) on Wednesday, April 17, 2002 - 12:54 pm:

[>In fact, this is the better way to do it, as you can still share code when
possible without causing any one platform to take a performance or stability
hit. ]

Yes, this is exactly our strategy.

[ As far as bandwidth usage goes, if you're doing this, and trying to limit
how much bandwidth SN takes, that's silly. From what I understand, SN uses
fairly constant communication during rendering across a network. So you want
the biggest bandwidth available.]

SN has extremely low bandwidth requirements, as the communication between controller and nodes consists entirely in reading and writing tiny text files. The only place where network speed impacts is in the render node loading images/objects from the shared content directory. In general, this loading time is but a fraction of the per-frame rendering time, and if it is not, then that particular scene should probably just be rendered on single machine.

[If this network conversation is as continuous as it seems to be]

I don't think it is. there is a bit of 'ready-load-ready-render' back and forth, but most of the time the nodes are rendering away, and the controller is polling for file changes every few seconds.


[ Now, as far as SN goes, is it using BSD sockets under Mac OS X, or the OT shims? ]

Neither, it is just reading files. The shared directory, nodes and controller can all even be on a single machine.


[For one, factoring the application so you have a background
faceless kernel that does computations independently of the UI. That would
almost allow you to run it as a daemon, and render without having the
machine logged in]

LWSN is exactly that faceless rendering kernel, it does not actually have to be logged in, it only depends on where the user wants the source content to originate, and the result frames to accumulate.

[Aqua in Carbon is neither thread-safe
nor reentrant, so you can't thread the UI any better than you can in 9]

It certainly seems that the OpenGL in LW and modeler uses multiple processors. It is multithreaded at a very low level, which I consider one of the most amazing of Apple's OSX triumphs. It is rendering that LW needs multithreaded anyway, and it is.


[Just look at all the other discussion topics. How many are actually praising
NewTek for the more than adequate effort they are putting into their Mac products? The more common ones are all about
complaints and bugs and performance issues. ]

And this is generally true across the board. People don't come to praise stuff, just to find out about solutions to problems they are experiencing.

By Ed Mag (Ed_M) (205.188.195.181) on Wednesday, April 17, 2002 - 01:51 pm:

[[[an apparent unwillingness to let an Adobe programmer investigate the Lightwave source? (However much we'd like to see Chris get stuck in there!). ]]]

That's a whole other topic. That's why the sign NDA's and besides, Chris has reputation to uphold. NewTek should really consider letting him examine their code. Adobe doesn't make a competing product and Chris is one of the best AltiVec programmers on the planet right now.

[[[(What 3D app doesn't have 'performance' issues or bugs of some sort?).]]]

Bad reasoning and still not an excuse.

[[[It's faintly hubristic, too, to claim that the majority of Mac users are dissatisfied,]]]

Let's just deal with the ones that take the time and effort posting to the boards, eh? It is wrong to think that most people are "completely satisfied" if you ask me. I remember back in first grade the class was encouraged to ask questions because it was likely that other people had the same or similar questions. Anyway...

[[[ the codebase is poorly optimised;]]]

Well, the benchmarks aren't showing consistent results and when compared to PC's something is wrong somewhere. So, why not let someone with EQUAL experience optimizing for both platforms take a gander and see if there is indeed something amiss?

[[[ that ScreamerNet, as it stands, is hopeless and to conclude that Newtek should be rightfully chided for 'slacking' on the Mac side on the basis of all this 'evidence' ]]]

To conclude that "it works just fine" is just as bad. The fact is (unless I completely missed something) there is no technical specs available for ScreamerNet. zippo useful information. What about the throughput data that John C. Welch is curious about? I'm sure Dean can provide the necessary throughput numbers for his clustering architecture. still we've seen no benchmarks for ScreamerNet from NewTek. Nor have we seen any benchmarks to support or debunk their data. More technical information should be made available about ScreamerNet implementation.

[[[Newtek was the first company to bring a high end 3D application to both the Macintosh back in 1997(?) and to OSX last year. ]]]

And? What were they developing on prior to that? Hmmmm.

[[[It's obvious from Arnie's posts that resource is incredibly tight and that all efforts have to be prioritised rigidly. ]]]

Haven't the resources always been tight?

[[[In such a context, is it very surprising that the extent of mac-centricity you demand is not immediately forthcoming? ]]]

That's it exactly! This is the FUD that has been plaguing Mac development since Job's initially left the company. you go on:

[[[or that a willingess to go out on a limb to experiment with Mac clustering is not embraced wholeheartedly? ]]]

There is that uncertainty thing again. To be honest, I don't think it would have cost them a dime. Dean is a scientist. Still, he need a chance to make his point. He can do that if NewTek provides the appropriate information. The best part is that ScreamerNet doesn't have to go away. They can keep it around if they want. Again, this is another choice or option.

[[["Matt Craig is/was the LW Mac programmer that was mentioned and he is TEARING it up on the new version. The code that he is creating now is the most Mac integrated he has ever created. The Mac version never looked so good". ]]]

Fine. I'm glad that there is progress being made. Really.

[[[Whilst I'd love to see a revised GUI for Screamernet that took all of the complexity out of the process, I can't help thinking that I simply know too little about the Mac Lightwave market to understand just how many users would benefit and what other projects would have to be jettisoned. ]]]

Like I said, it's likely that Dean would do all the work.

[[[How many are looking for a more sophisticated render controller and how many just want to get Screamernet to work? ]]]

Good question. How many would be interested in something that was fast, sophisticated, easy to setup and worked well and wasn't fragile?

[[[For my part, if there's a toss up between developing a feature like a node based surface editing paradigm where individual maps can be 'shared' across multiple surfaces and surface attributes, say, and a clustering capability I would vote for the former every time even though it's not Mac-specific. ]]]

OK, but why would you choose the former?

[[[Given the strictures of this context, instead of sharpening your blade on Arnie's exposition of Newtek's current position, might it not be more constructive to take the debate on to where clustering fits in to the overall picture for Mac users - to find out just how big the potential market is for Dean's hard work;]]]

Deans technology isn't vaporware. It can happen. Now.

[[[to find out how much of the problem is related to the interface for Screamernet rather than the underlying technology and to clarify where other much-needed developments and fixes sit from a Mac perspective? ]]]

You see, that's just it, there isn't much in the way of ScreamerNet information available on the web. How about a ScreamerNet Technical Information/Data document straight from NewTek that anyone can examine? It's hard to know what makes ScreamerNet tick when there is very little information available. Oh, and then there is the throughput question that John Welch raised. How much data is is moving? He couldn't find anything.

[[[I could go on :-) but the point is that, however clunky, the existing Screamernet setup does the job I need it to do - I'd rather Arnie worked on any of the above in preference.]]]

I'm not sure exactly how to comment on this statement.

[[[The fact that there are several companies developing network rendering solutions with OSX clients only adds more weight to the argument that says Newtek should concentrate elsewhere. ]]]

And how much of that development relies on ScreamerNet in general? Let's face it, you can give an old jalopy a new paint-job, but it does nothing to help any underlying issues.


[[[It's too facile to characterise these responses by Arnie as negative or dismissive when, in fact, they're lucid and cogent explanations of why Newtek isn't yet convinced about the benefits of clustering.]]]

As Dean stated, things have changed in that respect.

--
Ed

By Paul Lord (Paull) (208.186.206.70) on Wednesday, April 17, 2002 - 05:17 pm:

>>http://www.LiquidDreamSolutions.com/
>> Has a Mac OSX client in beta for their butterfly net render render controller. They are soliciting testers.

Thanks Arnie!


BNR and all Lightwave Controllers, use the LWSN.exe (Batch render) to process the LW scene files. I like the way LWSN is setup. This gives me much more flexability to control the rendering of the Scenes.


Paul

By Beam Tracer (Beamtracer) (210.50.30.6) on Wednesday, April 17, 2002 - 05:28 pm:

It doesn't hurt to discuss the pros & cons of other rendering alternatives... as long as everyone remains civil.

It seems that many people are still unconvinced about the Mac's viability in a clustering situation. I think this stems more from the dominant market position that Windows has traditionally held in 3D, more than price issues with Mac hardware.

The Mac's position in high-end graphics is on the rise, and Apple's doing a lot of work to get it there. I truly believe that there is a very viable market for Mac clustering. There are cost benefits that can be factored into the equation that counteract the expensive hardware argument.

John C. Welch said that Altivec cannot be applied to network ops. Does this apply to Screamernet? I would have thought that because SN deals with single frames that Altivec would still be operational.

By Ed Mag (Ed_M) (205.188.195.193) on Wednesday, April 17, 2002 - 05:51 pm:

Beam, I'm glad to see that someone has picked up on what John was saying about AltiVec ops. ;-) Now if we could only hear from Dean. Somehow I get the impression that clustering is more-or-less insulated from that loss. Still, I'm wondering where all the performance data is regarding ScreamerNet. Surely someone out there has been benchmarking it. Mr. Devlin perhaps? Ted, If you've done any significant testing of ScreamerNet performance and have the data, John and others (myself included) would be interested in it. The same goes for anyone else that has benchmarked SN performance. It would be interesting to see the results from testing single platform farms (i.e., all PC and/or all Mac) and some tests involving a mixed-platform environment.

--
Ed M.

By Arnie (Arnie) (65.184.20.249) on Wednesday, April 17, 2002 - 06:51 pm:

Umm.. noone has mentioned Windows clustering.. I'm not sure it is possible. The Cluster competition for OSX is Linux, and it is barely competition, since they are about the same thing (i.e. a BSD kernel). You should not be using clustering and network rendering interchangeably. They are different.
Altivec happens on numbers that are adjacent in memory, so of course it cannot apply over a network, but LWSN does not render over a network, it renders on a machine, with the full benefit of the altivec optimized rendering code. LWSN is controlled by another app, The Controller, which is commonly, but not necessarily, on a different machine, on a network. This whole thread is such a morass of confused terminology and misunderstanding, it is incredible.
The data and benchmarks that John is asking for are based on his wrong assumptions. The performance of a node will basically match the performance of layout on that machine, with very tiny network-based overhead. Thus the performance of a mixed platform render farm can be calculated from the performanced of its nodes.

By Beam Tracer (Beamtracer) (210.50.30.6) on Wednesday, April 17, 2002 - 06:54 pm:

Is Liquid Dream anything like Wet Dream? Sorry, I should shut up and not crack jokes.

Interesting that Paul is supportive of Screamernet, even though he created an alternative (ButterflyNetRender).

By Arne Kaupang (Arnek) (217.70.229.51) on Thursday, April 18, 2002 - 02:03 am:

Well, Paul sent me the beta of the so-called OSX version of the Butterfly Net Renderer. I say the so-called OSX version as you have to run the Controller app on a networked Windows machine (!) or as Paul says "you might be able to run it on Virtual PC"...
I don't have a Windows machine or Virtual PC so this doesn't help a lot. Let's hope the finished app is a stand-alone OSX product.

By Julian Johnson (Julianjohnson) (193.128.225.131) on Thursday, April 18, 2002 - 03:33 am:

[[[That's a whole other topic. That's why the sign NDA's and besides, Chris has reputation to uphold. NewTek should really consider letting him examine their code. Adobe doesn't make a competing product and Chris is one of the best AltiVec programmers on the planet right now.]]]

There's no question that having someone like Chris look at the code might be beneficial but the whole idea presumes that a) Newtek's existing optimisations for 7b with Sanjay were somehow half-baked and that further optimisations were not investigated b) that they're not already looking at it c) that Chris has a deeper understanding of the issues involved in writing parallel code for LIghtwave than Arnie, Stuart, Allen, Matt etc and d) that now is a suitable time to focus on further altivec optimisations in the context of all the other developments that must be going on with Lightwave. It's these *presumptions* that I find so strange..

[[[Bad reasoning and still not an excuse.]]]

You seem to use the existence of bugs as evidence of Newtek's lip service to Mac users when its a simple fact of programming life, as you know. Do the bugs in the intial release of Illustrator 10 demonstrate a lack of commitment by Adobe to the Mac?

[[[Let's just deal with the ones that take the time and effort posting to the boards, eh? It is wrong to think that most people are "completely satisfied" if you ask me. I remember back in first grade the class was encouraged to ask questions because it was likely that other people had the same or similar questions. Anyway...]]]

Who on earth would claim all Mac users are satisfied? My point was precisely the opposite - there's a much broader context than the one you see on this board. There are satisfied *and* unsatisfied users. Why constrain the parameters of this discussion in that way?

[[[Well, the benchmarks aren't showing consistent results and when compared to PC's something is wrong somewhere. So, why not let someone with EQUAL experience optimizing for both platforms take a gander and see if there is indeed something amiss?]]]]

I'm not sure what you mean be consistent results. The LW Mac benchmarks are hugely consistent on a machine by machine basis. The differential between G4 and Intel rendering times is also consistent. Whether this issue can be resolved by Altivec is at the heart of the debate. You presume it is. I don't know. Whether there's something 'wrong' or whether the G4 isn't as fast for the kinds of operations Lightwave requires has been a subject of debate for years..

[[[To conclude that "it works just fine" is just as bad. The fact is (unless I completely missed something) there is no technical specs available for ScreamerNet. zippo useful information. What about the throughput data that John C. Welch is curious about? I'm sure Dean can provide the necessary throughput numbers for his clustering architecture. still we've seen no benchmarks for ScreamerNet from NewTek. Nor have we seen any benchmarks to support or debunk their data. More technical information should be made available about ScreamerNet implementation.]]]

You have to accept that software development is always compromised in some way. It's totally valid to argue that Screamer, as it stands, is 'good enough' if making it better diverts resources away from other parts of the application. Given that, as it stands, it parcels up frames and enables them to be rendered across multiple machines, I'd say it works. It may be utilitarian and rather rudimentary but it does the job required of it whilst enabling third party developers to enhance it.

As Arnie has pointed out, your questions seem to be based on a thorough misunderstanding of the way LWSN works and the networking protocols it doesn't use. Each LWSN node renders at exactly the same speed as the host machine using the altivec optimisations that were incorporated in the 7b update. The protocol, as it is, is a simple set of text strings that get written into a shared directory - Arnie's enumerated most of the commands here.

[[[And? What were they developing on prior to that? Hmmmm.]]]]

Ed - I'm not sure what you're alluding to here?

[[[Haven't the resources always been tight?]]]]

Yes, which is why you need to put efforts to bring a clustering solution to the Mac into a prioritised context - there are millions of 'nice to have' projects and only a few that will eventually get developed by Newtek. Which are they to be? And should a clustering solution be one of them?

[[[That's it exactly! This is the FUD that has been plaguing Mac development since Job's initially left the company. There is that uncertainty thing again. To be honest, I don't think it would have cost them a dime. Dean is a scientist. Still, he need a chance to make his point. He can do that if NewTek provides the appropriate information. The best part is that ScreamerNet doesn't have to go away. They can keep it around if they want. Again, this is another choice or option.]]]

If you understand that there is little Newtek have to do and, if you now realise that much of the relevant 'documentation' and information for how LWSN works is actually within this thread, why berate Newtek for not cooperating or helping with a clustering solution when they patently have? I've never seen Arnie so diligently responsive or so courteous in the face of rather unwarranted provocation. Where is this fear, uncertainty and doubt that you talk about? Aren't we just talking about pragmatic prioritisation and sane product development for Mac users? Why does the tone of this have to degenerate into paranoia and suspicion?

[[[Good question. How many would be interested in something that was fast, sophisticated, easy to setup and worked well and wasn't fragile?]]]]

No one in there right mind would turn their nose up at a revised Screamernet. That's not the question. It's where such an enhancement should sit in the context of many others..

[[[OK, but why would you choose the former?]]]

Isn't it obvious why a Surface Editor that allowed you to share layers/surfaces across attributes would be a massive workflow improvement. Where you might use the same image map and gradient layer sequence on diffuse, spec, gloss, reflection etc. and have to manipulate each one separately you could just manipulate one....

[[[You see, that's just it, there isn't much in the way of ScreamerNet information available on the web. How about a ScreamerNet Technical Information/Data document straight from NewTek that anyone can examine? It's hard to know what makes ScreamerNet tick when there is very little information available. Oh, and then there is the throughput question that John Welch raised. How much data is is moving? He couldn't find anything.]]]

I think you should be able to see from Arnie's responses that you're presuming there is more to Screamernet than there really is.

[[[And how much of that development relies on ScreamerNet in general? Let's face it, you can give an old jalopy a new paint-job, but it does nothing to help any underlying issues.]]]

All of the development relies on using LWSN and the simple set of protocols written into text files that it obeys. The very simplicity of LWSN lends itself to solutions like those offered by Paul and those utilised in house by Kent at Industrial Light and Magic. The underlying issues are far less problematic for most users than the 'overlying' ones - the GUI is just too sparse. 80% of the problems users have with LWSN could be resolved by adopting a GUI similar to D-Storm's LWSN Controller.


Ed - it gets difficult to make these messages coherent as they get longer and the discussion gets more elaborate. If I grossly simplify your views it would go like this: you think that Newtek's apparent reluctance to provide information to Dean and/or to develop a clustering solution itself; its lack of comment on whether it will or will not discuss altivec optimisations with Chris; and the bugs and performance issues you see in Lightwave all indicate a poor effort by Newtek on the Mac side and only 'lip service' to Mac users.

Apart from the fact that I think each of the pillars of your argument is slightly shaky (Newtek have been cooperating and providing information; Newtek are and have worked on Altivec developments; there are bound to be bugs in Lightwave PC and Mac). My disagreement with you is simply on that conclusion. There is much evidence to suggest that Newtek are committed to the Macintosh and Mac users - evidence ranging from the altivec enhancements in 7b to the historical commitment Newtek has shown to the Mac and to comments like those made by Arnie here and Brad on Postforum. To call Lightwave Mac only an 'adequate' effort is to ignore the obvious fact that it is an application designed to excel at modeling and rendering which it does.

Your conclusion seems to be based on a very narrow context and a very short timetable - as though you can browbeat an immediate response out of Newtek on a set of specific and complex issues. When faced with a response or non-response that is not to yor liking you suggest that one of the Senior Lightwave Engineers takes a 'sabbatical'.

At the same time, you seem to have very little hands on experience with Lightwave Mac or directly with LWSN and little to no understanding of the underlying protocols and yet you continue to assert that LWSN is a 'jalopy'.

I'm really impressed with the way you've brought Mac luminaries into this debate and your improving zeal, but I get a sense that you're not actually listening to the responses you're given and that you're moving to a position which casts Newtek as anti-Macintosh when it quite patently isn't.

Julian

By kent (Kent_M) (63.203.68.200) on Thursday, April 18, 2002 - 08:04 am:

Wow, This all very nice, but man oh man...

It seems to me that there are two discussions going on here - no, three: Clustering, Screamernet Alternatives, and Newtek Mac Issues. Going back to the Screamernet Alternative thread, the 'solution' I hinted at earlier in the thread is a viable option that can be built to work in hand with the existing SN system with very little trouble, using all of the advantages that exist in SN but removing all of the irritants. Basically a 'render manager'.

My impression is that Mr. Dauger is not going to be writing any LW net render solutions; he has his own projects going on.

But a thing like this is not that hard to make, once the concepts are in place. If any of you programmers, or even Arnie, are still reading this thread and are interested in how this manager works send me a note and I'll describe the methods inherent. I don't think I can get in trouble for just doing that. Then someone will have to write the code and I can't help with that. The company this was implemented for is Industrial Light & Magic and it works very well.

~Kent
kbmatlaw@pacbell.net

By John C. Welch (Jcwelch) (18.174.0.40) on Thursday, April 18, 2002 - 08:29 am:

[[ Now, as far as SN goes, is it using BSD sockets under Mac OS X, or the OT shims? ]

Neither, it is just reading files. The shared directory, nodes and controller can all even be on a single machine. ]

Um, if it's talking to an OS X box across a network, it's using either BSD, or if Carbon, it has the option of using the OT shims. But you have to be using one or the other, otherwise, you're using sneakernet.

[LWSN is exactly that faceless rendering kernel, it does not actually have to be logged in, it only depends on where the user wants the source content to originate, and the result frames to accumulate. ]

Oh good, that makes things much better.

[[Aqua in Carbon is neither thread-safe
nor reentrant, so you can't thread the UI any better than you can in 9]

It certainly seems that the OpenGL in LW and modeler uses multiple processors. It is multithreaded at a very low level, which I consider one of the most amazing of Apple's OSX triumphs. It is rendering that LW needs multithreaded anyway, and it is.]

Okay, disconnect here. I'm talking about the UI, not just OpenGl. Aqua is not multithreaded or reentrant under Carbon. If you'd like, I can quote you from the specific tech note. If you aren't using Aqua for rendering, and why would you be, you aren't getting hit with this issue. but for UI slowdowns, in Carbon, that's the source of a lot of it.

[Umm.. noone has mentioned Windows clustering.. I'm not sure it is possible. The Cluster competition for OSX is Linux, and it is barely competition, since they are about the same thing (i.e. a BSD kernel). You should not be using clustering and network rendering interchangeably. They are different. ]

Arnie...first of all, clustering is most certainly possible on Windows, via a number of different methods, Marathon and Legato come to mind. Secondly, Linux is not a microkernel architecture, and never has been, never will be, as Linus Torvalds' opinion on microkernels are "They're garbage." Linux clustering is quite mature, as some of the massive implementations being used by the DOE and the DOD show.

I think one of the biggest issues is the lack of clarity that results when you can't easily get to the facts. If NewTek were to publish some specifications on SN, like protocol(s) used, throughput data on different systems, etc., then they might get more intelligent comments on SN. TechDocs are critical to anyone running any sort of network, and that's what SN is, a network. At least if you get that info out to the IT people running the networks that SN uses, you might get a couple of tips that you wouldn't have thought of because you don't have their mindset.

john

By Arnie (Arnie) (65.184.20.249) on Thursday, April 18, 2002 - 09:39 am:

John,

[Um, if it's talking to an OS X box across a network, it's using either BSD, or if Carbon, it has the option of using the OT shims. But you have to be using one or the
other, otherwise, you're using sneakernet. ]

OK I don't know what the method is because all the apps do to 'talk' is to use standard OS/ANSI file routines fopen() fprintf() and fclose(). In most cases the files reside on a shared directory on a machine connected via LAN. You can tell me how OSX carbon apps fopen() is implemented. I assume it is whatever the filesystem uses for networking.

[ but for UI slowdowns, in Carbon, that's the
source of a lot of it.]

Agreed, but for LW, the most critical UI parts are OpenGL, which is damn lucky.

[Linux is not a microkernel architecture]
Ok so linux is not based on FreeBSD as OSX is, and Dean's clustering is not a variation on Linux Beowulf clustering. I stand corrected. None of this is particularly relevant to LWSN.


[ At least if you get that info out to the IT people running the networks that SN uses, you might get a couple of
tips that you wouldn't have thought of because you don't have their mindset]

Well IT people at large production facilities have only been helping to tune screamernet for 10 years, so there is surely room for improvement. This is probably a large part of the problem: because only experts have been really using renderfarms, the node installation procedures are not simple and foolproof enough for animators to master reliably. To date most of our renderfarmers have had IT staff to hook them up.

tell me what actual data/stats you would like to see. What throughput are you asking about? How can it be relevant in light of my explanations in this thread of the minimal network dependence of LWSN performance?

By Paul Lord (Paull) (208.186.206.70) on Thursday, April 18, 2002 - 11:32 am:

ScreamerNet (aka. LWSN) is a application that is used to batch render scene files. Basically it is a text app that will render 1 frame or many frames depending how you execute the command.

BNR and all the other Lightwave Controllers Must use this application to render the scene frames. BNR 'Controls' the execution of this application on a network of computers. So think of the Controller as the Commander that is telling the 'workers' LWSN.exe what to do (i.e.: load scene 'testbox.lws', render frames 1-5, output frames to r:\netrender\testbox)

Think of the LWSN.exe as the text version of Lightwave Layout. Without it BNR could not create anything from the LW Scene files.

As for Clustering - If your talking about having more than 1 machine create a rendered frame - This can already be done with BNR and the Split frame support (which a few other controllers can do also) Basically BNR will cut the scene file into slices and tell the Client machines to render the slices, then after all the slices have been created - BNR will put them back together.

But as processors getting faster and faster, rendering a single frame on more than 1 machine will not matter. A single machine will be able to create a frame in a reasonable amount of time. Isn't that what we are talking about anyways - the speed of creating a rendered frame? And being about to create rendered frames on more than 1 machine?

No doubt clustering is a Cool idea! But, so where all the Dot.com ideas - and we all know what happened to them. The question should be not can Newtek add clustering, but SHOULD Newtek add clustering.


Paul

By John C. Welch (Jcwelch) (18.174.0.40) on Thursday, April 18, 2002 - 12:02 pm:

[OK I don't know what the method is because all the apps do to 'talk' is to use standard OS/ANSI file routines fopen() fprintf() and fclose(). In most cases the files reside on a shared directory on a machine connected via LAN. You can tell me how OSX carbon apps fopen() is implemented. I assume it is whatever the filesystem uses for networking.]

Well, lets see, there are at least three major protocol families to use for creating the connection, 4 major networkable filesystems. This is before SN can even *see* the shared directory. If you are using a networked filesystem that has a lot of overhead to initiate and maintain, then that's less CPU available to render, as the CPU is also dealing with mainaining the connection. But what you are talking about happens after the network connection and mounting is finished. What I am asking about happens before that.

[[Linux is not a microkernel architecture]
Ok so linux is not based on FreeBSD as OSX is, and Dean's clustering is not a variation on Linux Beowulf clustering. I stand corrected. None of this is particularly relevant to LWSN.]

Well, maybe it is. Again, the way SN works for providing network connections and shared directories, a method that is very efficient on one platform will kill you on another. For example, on Mac OS 9, to check the status of a connection, you use polling. That same technique on Mac OS X, because of the differences in the networking stack and the OS, will eat 90-95% of your CPU, killing the performance of anything else on that box. So a poor decision in your connection maintenance routines will significantly degrade the rendering performance.

[tell me what actual data/stats you would like to see. What throughput are you asking about? How can it be relevant in light of my explanations in this thread of the minimal network dependence of LWSN performance? ]

protocols used for connection and traffic, shared directory protocols, packet sizes, connection maintenance methods, and a nice packet trace for different platforms would be a good idea as well.
and if you are maintaining a constant connection to a shared directory, you have more network traffic than you think, but that is protocol dependant.

By Ed Mag (Ed_M) (152.163.201.192) on Thursday, April 18, 2002 - 01:01 pm:

[[[There's no question that having someone like Chris look at the code might be beneficial but the whole idea presumes that a) Newtek's existing optimisations for 7b with Sanjay were somehow half-baked and that further optimisations were not investigated]]]

Then it also raises the following questions: a) Are we to assume that Sanjay was only and specifically helping NewTek optimize Lightwave or was he helping tens of other developing companies as well. b.) Of what level of assistance was the help. Was it simply understanding the basic functionality of AltiVec or was it simply having Sanjay do the optimizations for them? Was it assistance with a vastly complex situation, algo, whatever... that even Sanjay needed to explore?

Chris has already stated that he's been working with Sanjay for quite some time now. The difference I get when listening to what Chris is saying is that Chris seems to have an uncanny, intimate (almost otherworldly?) grasp of Apple's hardware and Motorola's AltiVec, And Chris's expertise is not only limited to the 2D space. Chris was coding, testing, troubleshooting AltiVec code on Macs before there were any decent tools to assist. I remember Dave K. Every telling me in an e-mail that he met Chris Cox once at an AltiVec developers meet for some AltiVec coding tutorials. Dave was astonished at how far ahead of the curve Chris already was compared to everyone else. Jokingly, Dave surmised that possibly *Chris* should have been the guy instructing the class. I've been talking with Dave K. Every for years now and the guy never BS'd me. Besides, Dave isn't the only developer to give Chris high marks. Almost everyone I talk to that has some connection to Mac development hold Chris in high regard.

[[[b) that they're not already looking at it]]]

Looking into what? Having Chris look at the AltiVec implementation within Lightwave? Oh I'm sure (or I'd like to think) that there are already behind the scenes discussions going on between Chris and NewTek engineers.

[[[c) that Chris has a deeper understanding of the issues involved in writing parallel code for Lightwave than Arnie, Stuart, Allen, Matt etc. ]]]

Well, we are going to see. As I stated earlier, Chris has intimate knowledge of Apple's hardware, software and AltiVec. How about we turn that question around. Besides, this is an unimportant presumption. The fact that someone wants to help (someone of Chris's caliber that is) should be more than enough and met with open arms. Anyway, we are getting off topic here. This forum was meant to discuss how *Dean* can work with NewTek.

[[[d) that now is a suitable time to focus on further altivec optimisations in the context of all the other developments that must be going on with Lightwave. It's these *presumptions* that I find so strange.. ]]]

What are you talking about? I'm not sure what you are implying? Financial difficulty I could understand, but more on that later... Do you mean getting the rest of the code to work as advertised? Again, I'm not sure. If it is the latter then such companies (Micro$loft is a prime example) should concentrate on fixing their current offering to near perfection (i.e., as bug-free as possible, including functionality, stability, etc.) before they add anymore bells, whistles, features et al. Forgive me I'm not exactly sure what you meant by suitable Tim. As stated earlier, if it's a matter of expense, then I can understand that, but think about the vicious cycle you are dealing with there... For example, a company hits some challenging times, What's the first thing they do? They either look to cut help or shelve potentially beneficial projects that might be able to pull them through. You see, when you cut the help, someone has to pick up the slack and as a result, the products and services are negatively affected as well. Customers pick up on this and can tell when the products or services are "slipping" and if that happens, the company risks loosing potential customers. What happens next? The company decides to cut back even more and then the cycle continues... Look at Apple, They are defying the entire industry! Companies are chopping and shelving potentially killer projects and along with them, skilled jobs. Apple on the other hand continues to hire the experts and expand. Lessons can be learned from Apple. When times are tough, it's time to capitalize; especially when you know the competition will be doing what they normally do when times get tough.


[[[You seem to use the existence of bugs as evidence of Newtek's lip service to Mac users when its a simple fact of programming life, as you know. Do the bugs in the initial release of Illustrator 10 demonstrate a lack of commitment by Adobe to the Mac?]]]

Nice loaded question. It's not Adobe we are discussing here.

[[[Who on earth would claim all Mac users are satisfied? My point was precisely the opposite - there's a much broader context than the one you see on this board. There are satisfied *and* unsatisfied users. Why constrain the parameters of this discussion in that way?]]]

It is my belief that unsatisfied as well as "already satisfied" are interested in what Dean (and Chris) are offering NewTek.

[[[Whether this issue can be resolved by Altivec is at the heart of the debate.]]]

Wrong. Not *only* AltiVec. Chris can help with other areas of code too.

[[[G4 isn't as fast for the kinds of operations Lightwave requires has been a subject of debate for years.. ]]]

You mean double-precision? From talking to Chris, the Mac might have an advantage there as well. We can only wait and see what he thinks after see the code.

[[[You have to accept that software development is always compromised in some way. It's totally valid to argue that Screamer, as it stands, is 'good enough' if making it better diverts resources away from other parts of the application. ]]]

Dean said that he would handle the work.


[[[Given that, as it stands, it parcels up frames and enables them to be rendered across multiple machines, I'd say it works. It may be utilitarian and rather rudimentary but it does the job required of it whilst enabling third party developers to enhance it. ]]]

Sounds like you are talking about 3rd-party Windows development lol

[[[As Arnie has pointed out, your questions seem to be based on a thorough misunderstanding of the way LWSN works and the networking protocols it doesn't use. ]]]

OK, then how about you and Arnie break it down for all of us to see. Why not a tech. doc.? How about a list of the protocols? Something developers can take a gander at. Im sure John, Dean and Ted would all be interested in developing a deeper understanding of the underlying approach and technology. Just a thought. Perhaps this discussion has been worth while after all...

[[[The protocol, as it is, is a simple set of text strings that get written into a shared directory - Arnie's enumerated most of the commands here.]]]

Is there anyone out there that can send me a ScreamerNet config. file? Better yet send it to John Welch. His e-mail is: jcwelch@mac.com He want's to have a look at a few. (Thanks in advance)


[[[Yes, which is why you need to put efforts to bring a clustering solution to the Mac into a prioritised context - there are millions of 'nice to have' projects and only a few that will eventually get developed by Newtek. Which are they to be? And should a clustering solution be one of them? ]]]

OK, I'll bite, what are the top 5 things on NewTek's *Mac* "To Do" list?

You don't have to be specific. a vague idea would suffice. I'm just curious that's all. Besides, We are getting way off topic here. That isn't good. We should try to stay on topic. After all this is only a discussion forum, right?

[[[If you understand that there is little Newtek have to do and, if you now realise that much of the relevant 'documentation' and information for how LWSN works is actually within this thread, why berate Newtek for not cooperating or helping with a clustering solution when they patently have? ]]]

Look, I'll say it again. I LIKE NewTek. I REALLY DO! I like Arnie too, I like the fact that he actually takes time to provide feedback to the forum. I'll say it again, if I didn't like the company, the users, the software or the people, I wouldn't be here. I started this thread because Dean asked me to post it on the forum because he's been eager to work with a 3D company for a while on bringing this technology out. He wanted me to test the waters to see if any users would be interested. I suggested NewTek. I LIKE NewTek. Dean agreed and here we are. BTW, NewTek is the only company so far that Dean has approached.

[[[I've never seen Arnie so diligently responsive or so courteous in the face of rather unwarranted provocation. Where is this fear, uncertainty and doubt that you talk about? Aren't we just talking about pragmatic prioritisation and sane product development for Mac users? Why does the tone of this have to degenerate into paranoia and suspicion? ]]]

Arnie is a great guy (I mean that) He puts up with a lot of BS. Mine included.

[[[No one in there right mind would turn their nose up at a revised Screamernet. That's not the question. It's where such an enhancement should sit in the context of many others..]]]

Well, I haven't heard them even ask Dean what it would take to bring the technology to LW. Dean is willing to do the work. Ask Dean what he needs and THEN you can determine if it's unreasonable or not.

[[[I think you should be able to see from Arnie's responses that you're presuming there is more to Screamernet than there really is. ]]]

That's what many of us are curious about.

[[[Ed - it gets difficult to make these messages coherent as they get longer and the discussion gets more elaborate. If I grossly simplify your views it would go like this: you think that Newtek's apparent reluctance to provide information to Dean and/or to develop a clustering solution itself; its lack of comment on whether it will or will not discuss altivec optimisations with Chris; and the bugs and performance issues you see in Lightwave all indicate a poor effort by Newtek on the Mac side and only 'lip service' to Mac users. ]]]

Over distilled, but I do feel that more effort (better effort?) should be put into Mac Development. I think Ted Devlin aid it best. His last post begins like this:

[[[i have weighed in here, in this, discussion, as a user. As such, I do not need proof or some sort of offering to convince the programmer that his job can be done.

I am here to point out what, in my humble opinion is a confusing, half-hearted program design. ]]]

I tend to agree with Ted's entire post.

Best

--
Ed

By Dean Dauger (Dauger) (24.165.65.82) on Thursday, April 18, 2002 - 01:34 pm:

Hi,

Whoa! That's a lot of messages in a short time. I work with Dr. Decyk at UCLA for a day and everything here get rearranged. And it's so fast and furious that several posts have gone by while I've written this...

Okay, Arnie had a very interesting comment:

>> I am definitely not a clustering expert, but my understanding is that it is very similar, in terms of architecture requirements, to multithreaded processing. The main difference is that the 'threads' are running on different machines connected via LAN.

I'm afraid that's not accurate, mostly because the term "thread" has been overused. (Actually, that goes for the term "cluster" too.) The processes running on other nodes aren't "threads" of a multithreaded application or a multithreaded operating system. In the actual cluster implementation, the processes on each node are essentially just another application as far as the OS on each node is concerned. It just so happens that there are O(N^2) network connections between the N executables running on the N-node cluster. There is no underlying connection that tries to synchronize memory between nodes automatically to make it look like shared memory. Instead, the nodes pass messages to supply each other data when needed. This parallelization model is called "distributed-memory MPI" (Message-Passing Interface) and has become the predominant way for scientists and researchers to run codes on large numbers of processors. At some supercomputing centers, they are phasing out other methods completely.

A lesson that's been learned in high-performance scientific computing is that distributed-memory message-passing has emerged as the best way to achieve high-performance, high-efficiency codes. Codes that use shared-memory, whether the sharing is real or virtual, have been found to perform best when you partition the memory and pretend it was distributed memory anyway. For further reading, I suggest "In Search of Clusters" by Gregory F. Pfister for a detailed comparison of the approaches and other examples.

So, it just so happens that a job running on a Mac cluster fundamentally consists of distinct executables with all-to-all network connections, but from the point of view of the coder, you can write in such a way that the code on each node does its job and sends and receives data when it needs it. There are some simple source code examples on this page:

http://exodus.physics.ucla.edu/appleseed/dev/developer.html#MacMPI

>> .... This is why I have doubts about breaking the render process into finer granularity than one frame per node.
>> Since most calculations are only valid for 1 frame duration, breaking the process at one frame per node does not force multiple nodes to duplicate the mesh deformation, texture calculations, illumination, etc. performed by another node.

As I said earlier, I probably wouldn't want to break the task down to less than one frame per node. In fact, I would tend to assign many frames of an animation at a time to a processor.

What I'm seeing is that there is probably a way to work on LightWave's parallel render incrementally. I could start with the UI-less background only LW renderer and assign it a part of the render problem. This could be controlled centrally by node 0, or it's possible for all the nodes to coordinate in such a way so they figure out what parts to work on on their own. Which way I'd go depends on the how that render node code is already structured. I could start with treating LW's frame renderer as much as a black box as I could.

I'm getting the sense that the shared directory is being used for two purposes: 1. Shared input data, and 2. message-passing. The first could make sense given that the input files could be gigabytes in size. Even so, I've written simulation and analysis parallel codes where node 0 reads in large chunks of data from a large (up to gigabytes) file residing on its local disk and slices and dices it into the appropriate chunks that each of the other nodes need. It's a one-time initialization step, and, during computation, the other nodes have access to their data either in ram or, if it's too big, in a temporary file on its local disk.

As for the second purpose, I've found that message-passing via a shared disk can work, but it sometimes is unreliable and naturally makes the server of the shared directory an unpredictable bottleneck. If it's a "kick-butt" server, then it probably would work, but I wouldn't want to count on all users having that. I would want to see the message-passing between nodes done through calls to MPI, which sends messages peer to peer over the network, rather than through a central server.

(On the other hand, if the demands on the server are always low, then the performance hit might not be too bad. But I think a central server is something more for the user to correctly configure; I would consider that usability issue important too.)

Again, this can be done incrementally. As a first pass, I might not change LW's use of purpose 1 or 2 of the shared directory. As a next step, I would want to change #2 first, then #1 later. But to try these more advanced ideas I would need to poke around in the renderer's source.

I guess my instinct is to remove bottlenecks in the code as much as possible. In the context of parallel computing, decentralization is often a good approach to avoiding serial-type bottlenecks. That's the problem with shared-memory approaches, because the memory access becomes a bottleneck. That's a lesson I try to carry to other codes. But the cluster approach lends itself to peer-to-peer, decentralized parallelization very simply, and the nature of the API and the memory model "encourages" a parallel coder to code that way. This approach may open up possibilities that weren't obvious before.

For now, I can try to find those LW SDKs, and see how much I can do at that level. For more detailed information about what I'm talking about, I hope the people here have a chance to read the links and references I've posted already.

Thanks,
Dean

By Arnie (Arnie) (65.184.20.249) on Thursday, April 18, 2002 - 01:44 pm:

Paul and Dean should collaborate!

John:
[But what you are talking about happens after the network connection and mounting is finished. What I am
asking about happens before that. ]

There is no control over what happens before that. That is up to the user and the OS. screamernet could work over sneakernet, with the shared "command directory" on a floppy.. There is no continuous connection to a shared directory, just an ocassional quick glance at a file or two.

[gain, the way SN works for providing network connections and shared directories, a method that is very efficient on one platform will kill you on
another]

If the OS choses a bad method for sharing directories, then that is a bad choice, and the OS should be fixed. This is totally out of the scope of lightwave, which is 3D software, not a filesystem.

[protocols used for connection and traffic, shared directory protocols, packet sizes, connection maintenance methods, and a nice packet trace for different]

I have no idea about any of this, as it is all handled by the filesystem. I don't know what a shared directory protocol is, all that matters is that there is a path to a file, and that that file can be read or written.
I think the problem is that our system is so simple, you can't grasp it, because you believe that the "net" in screamernet implies some explicit network technology.

Ed:

[Is there anyone out there that can send me a ScreamerNet config.]

The screamernet configs are identical to the lightwave layout configs.. they have all the plugins listed, lots of other settings, a content directory path, etc. Most of the critical settings (other than plugins) are overridden by commandline options. These are only command and content paths anyway.

By Julian Johnson (Julianjohnson) (158.152.33.115) on Thursday, April 18, 2002 - 02:03 pm:

[abandoning the almost unreadable quote format]

Ed - No, you misunderstand me almost completely :-) I am not questioning the value of Chris's potential contribution or his calibre as a programmer. I'm questioning the way you have assumed that Newtek are not and have not been working on this issue and your assumption that Newtek can accommodate an approach from Chris, however welcome, at this juncture. The fact that there's no response from Newtek shouldn't lead you to infer that they're not looking at it or to berate them for not doing so. They may be operating on a different timescale to the one you'd like to see on different areas of the application. That is what I mean by a suitable time. I'm not implying anything about the current economic climate or the recent spate of events in the 3D industry.

Newtek have never made any performance claims for 7b other than it is optimised for altivec - which it clearly is if you contrast benchmark times for 7b with 7. How can that be construed as the code not working as advertised?

I have no argument with Dean getting all the information he needs to develop a killer clustering application for Lightwave, it would be damned cool. Nor have I any beef with Chris dismantling the Lightwave codebase and reforming it into something faster. My beef with you is simply your blithe dissing of Newtek without seeming to appreciate their fundamental commitment and an unwillingess to see that clustering *may* not be an absolute priority for them (or other Mac users like me). That's all.

I have absolutely no idea what Newtek's Top 5 Mac To Do items are :-). I would hazard a guess that they bear very little relation to mine...

It's good to see you want more effort put into Mac development. We all do.
Castigating Newtek for either not responding to you or not developing what *you* want them to develop at a time when you think it is appropriate is where we differ. Arnie's been trying to provide you with the available resources and information throughout this thread but you still seem to think something is being held back.

It's obvious you're trying to do all Mac Lightwavers a great service and from the responses so far, it's clear that many Mac users are desperate for a new network rendering solution. It's been fantastic to see all of these contributions and, for what it's worth, as much as you really LIKE Arnie and Newtek, I LIKE you :-)

Julian

By John C. Welch (Jcwelch) (18.174.0.40) on Thursday, April 18, 2002 - 03:04 pm:

[[But what you are talking about happens after the network connection and mounting is finished. What I am
asking about happens before that. ]

There is no control over what happens before that. That is up to the user and the OS. screamernet could work over sneakernet, with the shared "command directory" on a floppy.. There is no continuous connection to a shared directory, just an ocassional quick glance at a file or two.]

So SN is creating and tearing down the connection every time the nodes need to update? That's what it sounds like you are saying here.

[[gain, the way SN works for providing network connections and shared directories, a method that is very efficient on one platform will kill you on
another]

If the OS choses a bad method for sharing directories, then that is a bad choice, and the OS should be fixed. This is totally out of the scope of lightwave, which is 3D software, not a filesystem. ]

I'm getting the feeling that networking is not your thing. The OS doesn't *choose* anything. Secondly, the sharing protocol has nothing to do with the physical FS on the media. I can share HFS+ via NFS, SMB, HTTP, FTP, or AFP, and do this over tcp/ip or AppleTalk, (in the case of AFP)

As far as making the connection to the server, either the user does this, via connect to server, (in Mac OS X), or the application does by issuing the correct BSD socket or Open Transport commands. So as I can see from what you are trying to say there are two ways this happens:

1) You set up SN, tell the end nodes where the shared directory is, or vice-versa, and a low-level connection is made, data is transferred, and the connection is torn down. Every time any sort of information or data transfer is needed, this process is repeated. (I can't see why you'd be using a connectionless protocol where data integrity is a must.) In any event, doing it this way could be causeing you slowdowns on the end nodes, affecting rendering time, depending on how it's done.

2) The user creates a connection to the shared directory, mounts the directory, and SN works off of that. If *this* is the case, then you should rethink this. Depending on the sharing protocol used, you're creating quite a bit of overhead for yourself in areas that you shouldn't be. As well, for these types of connections, there can be a farily significant of network traffic, requiring the CPU to handle it, because you are using connections that are running much higher on the OSI stack than they should be. There is no real reason to be mounting drives on desktops for what is essentially a big fat set of RPC calls.

[[protocols used for connection and traffic, shared directory protocols, packet sizes, connection maintenance methods, and a nice packet trace for different]

I have no idea about any of this, as it is all handled by the filesystem. I don't know what a shared directory protocol is, all that matters is that there is a path to a file, and that that file can be read or written. ]

I think you are telling me that the user mounts these directories as if they were copying files to a file server. I really hope you are not doing that.

[I think the problem is that our system is so simple, you can't grasp it, because you believe that the "net" in screamernet implies some explicit network technology. ]

I'll bet you a copy of Lightwave that if you are connecting to a machine with ethernet, you're using a networking protocol. You may not realize that, but if you expect me to believe that you are transferring data about a network of many machines without one, it ain't gonna happen.

Now, the methods that SN is using may be that the user has to creat the connections manually at the UI level, and if this is the case, you're doing this *very* inefficiently, but SN is *not* transferring data over a network without a network protocol being involved. It also means that NewTek needs to hire some networking programmers.

But, let's run a test. Kill all the networking services on a Mac OS X box, and delete all the ethernet and networking kexts. I bet SN don't see nothing.

By John C. Welch (Jcwelch) (18.174.0.40) on Thursday, April 18, 2002 - 03:09 pm:

[[But what you are talking about happens after the network connection and mounting is finished. What I am
asking about happens before that. ]

There is no control over what happens before that. That is up to the user and the OS. screamernet could work over sneakernet, with the shared "command directory" on a floppy.. There is no continuous connection to a shared directory, just an ocassional quick glance at a file or two.]

So SN is creating and tearing down the connection every time the nodes need to update? That's what it sounds like you are saying here.

[[gain, the way SN works for providing network connections and shared directories, a method that is very efficient on one platform will kill you on
another]

If the OS choses a bad method for sharing directories, then that is a bad choice, and the OS should be fixed. This is totally out of the scope of lightwave, which is 3D software, not a filesystem. ]

I'm getting the feeling that networking is not your thing. The OS doesn't *choose* anything. Secondly, the sharing protocol has nothing to do with the physical FS on the media. I can share HFS+ via NFS, SMB, HTTP, FTP, or AFP, and do this over tcp/ip or AppleTalk, (in the case of AFP)

As far as making the connection to the server, either the user does this, via connect to server, (in Mac OS X), or the application does by issuing the correct BSD socket or Open Transport commands. So as I can see from what you are trying to say there are two ways this happens:

1) You set up SN, tell the end nodes where the shared directory is, or vice-versa, and a low-level connection is made, data is transferred, and the connection is torn down. Every time any sort of information or data transfer is needed, this process is repeated. (I can't see why you'd be using a connectionless protocol where data integrity is a must.) In any event, doing it this way could be causeing you slowdowns on the end nodes, affecting rendering time, depending on how it's done.

2) The user creates a connection to the shared directory, mounts the directory, and SN works off of that. If *this* is the case, then you should rethink this. Depending on the sharing protocol used, you're creating quite a bit of overhead for yourself in areas that you shouldn't be. As well, for these types of connections, there can be a farily significant of network traffic, requiring the CPU to handle it, because you are using connections that are running much higher on the OSI stack than they should be. There is no real reason to be mounting drives on desktops for what is essentially a big fat set of RPC calls.

[[protocols used for connection and traffic, shared directory protocols, packet sizes, connection maintenance methods, and a nice packet trace for different]

I have no idea about any of this, as it is all handled by the filesystem. I don't know what a shared directory protocol is, all that matters is that there is a path to a file, and that that file can be read or written. ]

I think you are telling me that the user mounts these directories as if they were copying files to a file server. I really hope you are not doing that.

[I think the problem is that our system is so simple, you can't grasp it, because you believe that the "net" in screamernet implies some explicit network technology. ]

I'll bet you a copy of Lightwave that if you are connecting to a machine with ethernet, you're using a networking protocol. You may not realize that, but if you expect me to believe that you are transferring data about a network of many machines without one, it ain't gonna happen.

Now, the methods that SN is using may be that the user has to creat the connections manually at the UI level, and if this is the case, you're doing this *very* inefficiently, but SN is *not* transferring data over a network without a network protocol being involved. It also means that NewTek needs to hire some networking programmers.

But, let's run a test. Kill all the networking services on a Mac OS X box, and delete all the ethernet and networking kexts. I bet SN don't see nothing.

By Michael Wolf (Lightwolf) (62.104.220.76) on Thursday, April 18, 2002 - 03:59 pm:

John,

I think Arnie is right. SN rendering is too simple for you to grasp. And, yes I can run LWSN on a networkless machine no probs. (that's what I used to do 6 years ago when I got my first dual processor machine, because running a dual LWSN config on one machine was much faster than one Lightwave multithreading). No networks attached, it works.

Please reread what Arnie wrote:
LWSN is an _extremely_ simple app (as far as controlling it is concerned). It doesn't really care about networks. It only uses simple C functions that the OS may execute on a networked drive if needed (i.e. fopen for file open, if the file to open happens to be on a mapped drive, than the OS uses a networking protocol, otherwise it may go straight to the local file system, its up to the OS to handle).

SN don't care about networking. A simple app that every now and then (I assume every couple of seconds), checks if something has been writen to a certain file (like "render", "wait", whatever), and every now and then writes its current status to another file (like "rendering", "render finished" etc.).

And, believe me, I've been network rendering for over 6 years now (using LWSN), and the networking part doesn't really affect the rendering speed at all. What affects rendering speed is the speed of the network if you need to load huge scenes with lots of image sequences / mapped videos. But, I guess if swapped out my 100BaseT against 10BaseT, I wouldn't really see much of a difference speedwise with most scenes I render. (Usually the render times are much higher than the time taken for i/o, I hardly ever saturate our network using LW renders).

O.k. Conclusion: LWSN is not a network aware app per se, it's just a command line renderer that can take commands from simple ascii files.
An improved LWSN with a tighter integration into Lightwave would be nice (in that sense, Real4D for the PC has some kind of render clustering built in).

Dean: Don't forget, we're talking rendering and raytracing here. It is very hard to predict which parts of a scene you really need on which node of your cluster. Rays can be basically fired anywhere, so you would need full copies of the scenes on every node in the cluster.

My last words here on the optimization issues:
The first thing you do when you optimize code is you try to refine and tweak you basic algorithm. There's no use in using super speedy altivec hand optimized assembler code if your basic algorithm sucks. Then you check for bottlenecks, see if you can tweak a code a bit more and see if you can tweak your compiler (AFAIK the switch from Microsoft C to the Intel C compiler provided quite a nice performance boost for LW intel). Then you might have a look at a profiler, see which code is beeing accessed the most, which code uses up most of the time and try to optimize that, may be even in machine code. But AFAIK that is only the last straw, and usually breaks of provides less of a benefit once you go backto refining your algorithms for the next rev or a new processor is released that needs a different optimizing strategy (on intel-> 486PentiumP4 all require different kinds of optimizations)..

Ooph, it's getting late, enough yakking...

Cheerio

Mike

By John C. Welch (Jcwelch) (66.189.8.109) on Thursday, April 18, 2002 - 04:52 pm:

[I think Arnie is right. SN rendering is too simple for you to grasp. And, yes I can run LWSN on a networkless machine no probs. (that's what I used to do 6 years ago when I got my first dual processor machine, because running a dual LWSN config on one machine was much faster than one Lightwave multithreading). No networks attached, it works. ]

that's fine. but guess what, if you are using a shared directory across a network, then youre' using a network. SN evidently isn't but the OS SN is running on is. Otherwise, there's no shared directory for the host computer to see.

Here's another thing that the people who decided that "We'll just use OS file sharing" didn't think about...it can eat your cpu up. You get some bad packets, your host connection gets wonky, and the host OS starts eating CPU cycles to either repair the connection, or kill it. In either case, the methods you have chosen have a *very* high potential for eating CPU cycles that should be used for rendering. If games were to use Newtek's method, i'd have to mount an Unreal Tournament server's drive to play UT...which means that I'm wasting a lot of CPU cycles on a connection that has no purpose other than to save the developer from having to know how networks work.


[Please reread what Arnie wrote:
LWSN is an _extremely_ simple app (as far as controlling it is concerned). It doesn't really care about networks. It only uses simple C functions that the OS may execute on a networked drive if needed (i.e. fopen for file open, if the file to open happens to be on a mapped drive, than the OS uses a networking protocol, otherwise it may go straight to the local file system, its up to the OS to handle). ]

Right. So you force the user to use Network Neighborhood, Connect to server, the Chooser, etc, to establish a user level connection so that SN only has to do local file reads and writes. you offload all the network handling to the host OS. well, unfortuneately, you are actually eating more CPU with that method than if you just used a simpler, lower level TCP connection.

[SN don't care about networking. A simple app that every now and then (I assume every couple of seconds), checks if something has been writen to a certain file (like "render", "wait", whatever), and every now and then writes its current status to another file (like "rendering", "render finished" etc.). ]

Right, it doesn't care. because the Host OS is using CPU to deal with it. More CPU than is necessary.

[And, believe me, I've been network rendering for over 6 years now (using LWSN), and the networking part doesn't really affect the rendering speed at all. What affects rendering speed is the speed of the network if you need to load huge scenes with lots of image sequences / mapped videos. But, I guess if swapped out my 100BaseT against 10BaseT, I wouldn't really see much of a difference speedwise with most scenes I render. (Usually the render times are much higher than the time taken for i/o, I hardly ever saturate our network using LW renders). ]

the point is, you are losing CPU to the host OS so that NewTek doesn't have to actually run a proper networking app. It may not be a lot of CPU, but if someone uses NFS, and the host mount dies, the nodes will eat all the CPU to deal with it. AFP times out faster, SMB times out slower. It's all pretty silly, you're using a file sharing protocol instead of a network data transfer protocol. Saves NewTek some work, but it's not efficient at all. Take a look at how games do this, they do it far better.

john

By John C. Welch (Jcwelch) (66.189.8.109) on Thursday, April 18, 2002 - 04:58 pm:

[I think Arnie is right. SN rendering is too simple for you to grasp. And, yes I can run LWSN on a networkless machine no probs. (that's what I used to do 6 years ago when I got my first dual processor machine, because running a dual LWSN config on one machine was much faster than one Lightwave multithreading). No networks attached, it works. ]

that's fine. but guess what, if you are using a shared directory across a network, then youre' using a network. SN evidently isn't but the OS SN is running on is. Otherwise, there's no shared directory for the host computer to see.

Here's another thing that the people who decided that "We'll just use OS file sharing" didn't think about...it can eat your cpu up. You get some bad packets, your host connection gets wonky, and the host OS starts eating CPU cycles to either repair the connection, or kill it. In either case, the methods you have chosen have a *very* high potential for eating CPU cycles that should be used for rendering. If games were to use Newtek's method, i'd have to mount an Unreal Tournament server's drive to play UT...which means that I'm wasting a lot of CPU cycles on a connection that has no purpose other than to save the developer from having to know how networks work.


[Please reread what Arnie wrote:
LWSN is an _extremely_ simple app (as far as controlling it is concerned). It doesn't really care about networks. It only uses simple C functions that the OS may execute on a networked drive if needed (i.e. fopen for file open, if the file to open happens to be on a mapped drive, than the OS uses a networking protocol, otherwise it may go straight to the local file system, its up to the OS to handle). ]

Right. So you force the user to use Network Neighborhood, Connect to server, the Chooser, etc, to establish a user level connection so that SN only has to do local file reads and writes. you offload all the network handling to the host OS. well, unfortuneately, you are actually eating more CPU with that method than if you just used a simpler, lower level TCP connection.

[SN don't care about networking. A simple app that every now and then (I assume every couple of seconds), checks if something has been writen to a certain file (like "render", "wait", whatever), and every now and then writes its current status to another file (like "rendering", "render finished" etc.). ]

Right, it doesn't care. because the Host OS is using CPU to deal with it. More CPU than is necessary.

[And, believe me, I've been network rendering for over 6 years now (using LWSN), and the networking part doesn't really affect the rendering speed at all. What affects rendering speed is the speed of the network if you need to load huge scenes with lots of image sequences / mapped videos. But, I guess if swapped out my 100BaseT against 10BaseT, I wouldn't really see much of a difference speedwise with most scenes I render. (Usually the render times are much higher than the time taken for i/o, I hardly ever saturate our network using LW renders). ]

the point is, you are losing CPU to the host OS so that NewTek doesn't have to actually run a proper networking app. It may not be a lot of CPU, but if someone uses NFS, and the host mount dies, the nodes will eat all the CPU to deal with it. AFP times out faster, SMB times out slower. It's all pretty silly, you're using a file sharing protocol instead of a network data transfer protocol. Saves NewTek some work, but it's not efficient at all. Take a look at how games do this, they do it far better.

john

By Arnie (Arnie) (65.184.20.249) on Thursday, April 18, 2002 - 06:12 pm:

[that's fine. but guess what, if you are using a shared directory across a network, then youre' using a network. SN evidently isn't but the OS SN is running on is. Otherwise, there's no shared directory for the host computer to see. ]

Yes finally you get my point. Your comparison to games is misguided, since they rely on minimal latency AND simultaneously are maxing out CPU and GPU.
I can fully believe that using the OS shared file mechanisms uses CPU cycles, is subject to inconsistent performance, latency, etc. but you must put this in perspective.
The time to read the 20 byte text file off the shared directory, which is the command or ack to or from the node will be less than a second. Hopefully alot less. in a worst case it will be less than 10 second. There will be about 10 such transactions alltogether per frame rendered, lets agree that the entire per frame overhead for this is 20 seconds, although on a decent lan, it should be FAR less.

Now consider the loading of the scene from a shared content directory. Now this directory COULD be local to the node, and duplicated on every node. This is a storage tradeoff decision made by the user. For many, the shared directory serves important team workflow purposes. Similarly, the shared content directory may be a framestore with gigs of digitized film frames, which they don't care to duplicate, and can barely even hold. The scene load could take a minute or more, loading megs and megs of textures and meshes. This time washes out the command messaging time. Unfortunately, the entire structure of scenes and interactive animation and rendering is based on file references, so using some other method for loading this data is not really plausible. It must come from a directory. Forcing each node to locally duplicate these resources would be a grave disservice to users.

Now we have 20s for communication, 1-3 minutes loading time. During all this communication, what does LW need the CPU for? Not much, it is just waiting to be set up. Any drag on the CPU from this communication does not take away from rendering.

It is rare for users to need a renderfarm for small or simple animations, so typical frame rendering will be AT LEAST 10 minutes a frame, and possibly hours per frame. During this rendering time, the rendering CPU is dedicated to rendering, except when the command directory is polled for progress by the controller, amounting contention for less than 1 second per minute.

In all, the impact on render time for network speed issues is basically negligible. I'm sure communication could be tuned with special networking code for each platform, and the code to let each of these schemes intercommunicate, but the cost for development, and the reduction in reliability would probably not be worth the barely noticeable performance improvement. Moreover, it is rare that users with renderfarms really care that much whether their farm spends 10 minute per frame, or 10 minutes and 20 seconds.

Michael, Paul, care to chime in with more accurate timings for any of my numbers above?

By Marcel Valcarce (Marcelval) (65.214.183.163) on Thursday, April 18, 2002 - 07:02 pm:

Time to chime in.

I was very interested to hear John Welche's comments and Arnie's reponse. And I am not sure Arnie is getting John's point. The real question I have for Arnie in regard to the Shared File System vs. direct network access from within the renderer is: How many CPU cycles are being eaten by the OS maintaining and tending the network connection during the actual rendering time. And, does the renderer pause during rendering when it is checking for messages.

I know from past experience that sometimes if a network connection fails (even if no application is reading or writing at that time) my mac will come to it's knees while the OS trys to recover the connection.

By Arnie (Arnie) (65.184.20.249) on Thursday, April 18, 2002 - 07:10 pm:

Marcel, the renderer never checks for messages while rendering, only the controller checks to see if the renderer has posted a new message.

If a network connection fails, a little slowdown would seem to be the least of your problems.

By John C. Welch (Jcwelch) (66.189.8.109) on Thursday, April 18, 2002 - 09:10 pm:

[I can fully believe that using the OS shared file mechanisms uses CPU cycles, is subject to inconsistent performance, latency, etc. but you must put this in perspective.
The time to read the 20 byte text file off the shared directory, which is the command or ack to or from the node will be less than a second. Hopefully alot less. in a worst case it will be less than 10 second. There will be about 10 such transactions alltogether per frame rendered, lets agree that the entire per frame overhead for this is 20 seconds, although on a decent lan, it should be FAR less. ]

But during the time when rendering is happening, whether SN or LW want it to or not, thanks to the user - level scheme you are using, there is still constant "do I still need this connection, yes you do." communications. As well, if any file in that directory gets changed, that creates traffic. If there is a problem with a switch port, that creates traffic. By forcing the machine to mount the drive, and for what you are doing, there is *no* reason to incur this overhead other than wanting to avoid doing any network coding, you leave yourself open to CPU slowdowns for too many other reasons.

I've been running Unixen, AS/400s, PCs, Macs, for years, and i have watched a wonky network connection cause the OS to devour the CPU, and unless you have a tight network management system looking for this, (which also eats CPU cycles, nothing's free), it can take a while to figure out what the hell is going on.

[Now consider the loading of the scene from a shared content directory. Now this directory COULD be local to the node, and duplicated on every node. This is a storage tradeoff decision made by the user. For many, the shared directory serves important team workflow purposes. Similarly, the shared content directory may be a framestore with gigs of digitized film frames, which they don't care to duplicate, and can barely even hold. The scene load could take a minute or more, loading megs and megs of textures and meshes. This time washes out the command messaging time. Unfortunately, the entire structure of scenes and interactive animation and rendering is based on file references, so using some other method for loading this data is not really plausible. It must come from a directory. Forcing each node to locally duplicate these resources would be a grave disservice to users. ]

You're only cosidering this from one point of view, namely that this directory has to be a mounted drive of some kind. It doesn't at all. you could use lower level, lighter weight protocols to transfer the data that needs to be rendered, start the rendering by an RPC command, which are quite lightweight, then transfer the finished data back. This can all be done without needing a connection that can be browsed in the Finder. The difference is, with this, *Newtek* has to write this code, instead of mounting the drive, and hoping the user picked a good sharing protocol to use.

[It is rare for users to need a renderfarm for small or simple animations, so typical frame rendering will be AT LEAST 10 minutes a frame, and possibly hours per frame. During this rendering time, the rendering CPU is dedicated to rendering, except when the command directory is polled for progress by the controller, amounting contention for less than 1 second per minute.]

Not on a pre-emptively scheduled machine it isn't. it can't be. There will *always* be CPU slices to service that user level connection, to ensure that any changes on the remote system are reflected by the node, etc. Maybe on Mac OS 9 you can eat the CPU alive by design, but on Unix, or even Winders, the CPU(s) are going to check on other processes rendering or not. The way SN is doing things is forcing unecessary processes on the CPU.

[Marcel, the renderer never checks for messages while rendering, only the controller checks to see if the renderer has posted a new message.

If a network connection fails, a little slowdown would seem to be the least of your problems. ]

If you're using static NFS mounts on the machine with the shared directory, and the NFS daemon barfs, (not an uncommon occurance on a heavily loaded box) it'll take every machine connected to it down as well. That's a reason to avoid running the connection at a higher OSI level than necessary.

By Arnie (Arnie) (65.184.20.249) on Thursday, April 18, 2002 - 09:38 pm:

[The difference is, with this, *Newtek* has to write this code, instead of mounting the drive, and hoping the user picked a good sharing protocol to use. ]

Yup, and it is just not worth it.

By Ed Mag (Ed_M) (205.188.200.43) on Thursday, April 18, 2002 - 10:38 pm:

[[[[The difference is, with this, *Newtek* has to write this code, instead of mounting the drive, and hoping the user picked a good sharing protocol to use. ]

Yup, and it is just not worth it. ]]]

It just isn't worth it? Again, Dean would most likely do the work that needed to be done. Has anyone bothered to weigh the tradeoffs of the current design as compared to an alternative? I mean a *real* list of pros and cons of each and how they compare? It's funny, but from what I've been reading, John seems to be doing a masterful job in explaining in detail what Ted Devlin has been saying (or attempting to get across) from the start about all the unnecessary overhead that's burning cycles.

--
Ed

By Michael Wolf (Lightwolf) (217.0.91.250) on Friday, April 19, 2002 - 03:38 am:

John,

I think to satisfy your needs, one would need to create a dedicated LWSN computer.

No OS (an OS eats CPU cycles), and a network protocol that could run at 2400bps.

Well, or maybe dedicated hardware (a la renderdrive).

Hey, this is the year 2002, I think all those fancy guis eat up more cpu cycles than the control part of SN ever will.

I would rather see NT optimize the renderer than see them fiddling around networking sockets.

Another thing would be of course if NT would drastically increase the functionality of network rendering (i.e. sliced single frame preview renders across the network...), but that's another story.

---

Mike

By John C. Welch (Jcwelch) (66.189.8.109) on Friday, April 19, 2002 - 05:14 am:

[Hey, this is the year 2002, I think all those fancy guis eat up more cpu cycles than the control part of SN ever will. ]

Create a shared directory at the user level. Bounce the connection a bit, while maxing out the bandwidth. Watch the OS eat the CPU...eat spot eat...it's not pretty. I still remember the screams of agony from people running really large IDL/ENVI runs on multiple machines when the backups would kick in, and the speed would just drop. The fact that NT thinks that none of that networking stuff affects them because they don't specifically network things is a fascinating, yet unrealistic POV.


[I would rather see NT optimize the renderer than see them fiddling around networking sockets.]

Well, they could do both. It's not like what I'm talking about is either hard or new. This kind of networking has been around for *decades*. Read up on the history of RPC, etc. Well documented, easy to write, stable, mature.

I won't even get into the security issues that this type of thing causes. All you need is BackOrifice on one of the render nodes, and your entire network is compromised. A retarded monkey with a packet sniffer and a small RAID could easily steal all the data going across as well. I'm assuming the people creating content on this would prefer it not be stolen.

[Another thing would be of course if NT would drastically increase the functionality of network rendering (i.e. sliced single frame preview renders across the network...), but that's another story.]

Well, since NT's stated position is that writing a *real* networking implementation isn't worth the effort. It would seem you never have to worry about that.

[[The difference is, with this, *Newtek* has to write this code, instead of mounting the drive, and hoping the user picked a good sharing protocol to use. ]

Yup, and it is just not worth it. ]

Which also drops your support costs...any problems related to a network situation, you can force the user to run about bitching at the OS vendor, the computer vendor, the switch vendor, the cable vendor, the NIC vendor, and only then have to deal with it. It's actually pretty masterful. I haven't seen something that slick since the last time I dealt with SGI.

john

By Michael Wolf (Lightwolf) (217.0.91.250) on Friday, April 19, 2002 - 05:41 am:

Oh my, I should get out of here

anyhow:
>>Create a shared directory at the user level. Bounce the connection a bit, while maxing out the bandwidth.

Why should I? LWSN doesn't bounce a lot and max out the connection, you're talking about a different kind of networking app / requirement here.

It is also not newteks job to keep my LAN clean.

I also prefer to handle my jobs in a server based environment instead of a peer-2-peer situation, because it allows me to optimize my internal LAN connections a bit better... (e.g. 1GB from server to 100MBit switch to workstations is the kind of config we'll run soon, which is optimized for server based operations and much more than we need right now for 10 renderfarm PC's anyhow).

It is their job to provide a fast and easy / simple network rendering solution, and that's all LWSN is. I don't even need to manually mount anything on my network, since we're NT only and only use UNC file names. As I said before, it takes me around a mouse click (with spider) to add a new machine to our LW renderfarm, I've co-written an LScript that sends the current scene from LW to the fram and renders it etc...

I'm accustomed to watching the CPU usage regularely to optimize render times. The OS doesn't affect the render times at all (at least NT doesn't), the only time the CPU usage goes below 100% is when LWSN is loading data, or during some render passes when running multithreaded on a dual proc machine (which is one area where I'd rather like to see NT optimize the renderer, multithread more, for example shadow map creation, VIPER, optimizing for raytracing, the whole "moving objects" part is all single threaded now and wastes plenty of idle CPU time).

>>Well, since NT's stated position is that writing a *real* networking implementation isn't worth the effort. It would seem you never have to worry about that.

It's not worth to effort for the current implementation of LWSN, which works fine within it's limited feature set. Adding "proper" LAN rendering only makes sense with a drastic improvement of the LWSN features which in turn would result in a custom kind of "clustering" which in turn is quite complicated (and I say "custom" because NT would have to optimize it for their very own rendering process).

So, I don't really see a point in doing much in-between those two extremes (From a practical "what I work with every day" POV. Mind you, render "controllers" (Like Stealthnet, Butterfly, Spider, Lightnet etc...) are a different thing alltogether.

As far as support costs are concerned... Even if you write a native networing app you can still "force the user to run about bitching at the OS vendor, the computer vendor, the switch vendor, the cable vendor, the NIC vendor, and only then have to deal with it"

Cheers,

Mike

By John C. Welch (Jcwelch) (18.174.0.40) on Friday, April 19, 2002 - 08:59 am:

[>>Create a shared directory at the user level. Bounce the connection a bit, while maxing out the bandwidth.

Why should I? LWSN doesn't bounce a lot and max out the connection, you're talking about a different kind of networking app / requirement here. ]

I'm talking about what happens when a connection maintained and managed by the OS goes wonky. On Winders, it's real fun to watch.

[It is also not newteks job to keep my LAN clean.]

No, but it is their job to use the cleanest and lightest wieght possible network methodology, which they aren't. BTW, I fuss at quite a few vendors over this sillines, it's not just NewTek. There are too many ways to handle this down low to not do it.

[I also prefer to handle my jobs in a server based environment instead of a peer-2-peer situation, because it allows me to optimize my internal LAN connections a bit better... (e.g. 1GB from server to 100MBit switch to workstations is the kind of config we'll run soon, which is optimized for server based operations and much more than we need right now for 10 renderfarm PC's anyhow).]

What's peer to peer about a low level connection? Nothing inherently. You just avoid the higher level overhead is all. Quite honestly, I'm glad to know how NT is not handling this, so when it becomes an issue on my networks, I can make sure that any SN rendering is completely detached from the rest of the network.

[It is their job to provide a fast and easy / simple network rendering solution, and that's all LWSN is. I don't even need to manually mount anything on my network, since we're NT only and only use UNC file names. As I said before, it takes me around a mouse click (with spider) to add a new machine to our LW renderfarm, I've co-written an LScript that sends the current scene from LW to the fram and renders it etc...]

UNC connections are manual user-level mounts, don't kid yourself. SN isn't any kind of network rendering solution. It's totally network blind, requiring far more work than if NT did it correctly. Oy vey, some RPC work, and you could make the setup far easier. "Enter the DNS names of the nodes. Thank you." get the IP addresses, establish a TCP connection, transfer the data, RPC the render request, and go idle until it's done. No need to involve the higher level garbage the UNC requires.

As well, your system is proof that SN is not easy to use, nor inherently flexible without writing custom scripts and bolting third party stuff onto it. It takes longer, and costs more money to do something with robustness and flexibilty, but your support costs drop down the road, and considering that the rule of tech support states that after your third support call, any profit from a sale is gone, you would think that this would be a no brainer.

john

By Michael Wolf (Lightwolf) (212.9.168.87) on Saturday, April 20, 2002 - 09:06 am:

Hi John,

I'm back :-)

>>I'm talking about what happens when a connection maintained and managed by the OS goes wonky. On Winders, it's real fun to watch.

So you want them to circumvent as many OS functions as possible, since there may be bugs and issues in the OS? In that case (I'm going over the top here, but I'm trying to bring my point across, so please excuse...), NT might as well sell Lightwave machines that run nothing else They could just as well (and for the same reasons), write their own 3D acceleration (openGL could be flaky), window management, memory management (which they had massive problems with during the first releases of LW for Win32 if I remeber correctly) and even only use direct low level disk accesses to load and save scenes and objects. Can't really trust an OS, can you

>>Quite honestly, I'm glad to know how NT is not handling this, so when it becomes an issue on my networks, I can make sure that any SN rendering is completely detached from the rest of the network.

Well, once SN rendering becomes an issue on your network, you'll probably need to scrap the whole network and rebuild it I'm mean, a network that doesn't even cater for simple file / volume sharing, what's that? That is just about the only reason why most facilities I know in the post world run a network in the first place, file sharing and centralized storage on a server. And compared to that i/o strain, the question of how SN controls the nodes is a non-issue bandwidth wise.

I brought up the P2P thing because this thread had something to do with clustering, and when I start a render of a scene from my workstation, and my workstation (or any workstation for that matter) starts sending around scene data to render nodes (as opposed to nodes getting their data from the server), then that's P2P to me.

>>UNC connections are manual user-level mounts, don't kid yourself.

True, but the user does not explicitly need to mount them for the OS to access them. Spider for example runs as a service on NT, and can even network render when no user is logged on, without any intervention on the rendering machine by a user.

>>SN isn't any kind of network rendering solution.

SN is(it allows you to render scenes across a network), but LWSN isn't. LWSN is not really much more than a commandline renderer.

>>It's totally network blind, requiring far more work than if NT did it correctly.

I agree that NT ought to release a decent network rendering controller, but this is not an issue with lwsn.exe itself (lwsn is the simplest solution one can think of, and sometimes these are the best given a certain amount of time and money, especially for developing).
They (NT) tried it once (Stealthnet, which even used TCP/IP ports directly to drive renderfarm services that in turn ran LWSN.exe. So at least Bob Hood from NT know how to pogramm on a low level network basis), but they failed, and Stealthnet seems to have disappeared from the "let's implement this on a high priority" list completely.

>>Oy vey, some RPC work, and you could make the setup far easier. "Enter the DNS names of the nodes. Thank you." get the IP addresses, establish a TCP connection, transfer the data, RPC the render request, and go idle until it's done. No need to involve the higher level garbage the UNC requires.

Well, Stealthnet and Spider don't even require you to enter the names of the nodes, they find them automatically. They both establish a connection to a demon running on the rednerfarm pc as a service and those local demons tell lwsn what to do (and what config file to use..). Lwsn then loads the scene (using normal file shares, just as Layout would) and starts rendering away. Simple.
If the demons where responsible for transfering the data needed, you would actually have a massive overhead in the whole system (how should the demon know which frame of an image mapped animation file is currently needed, it would also need to decode it, o.k. let's transfer the whole thing... How should it know that a 3rd party plugin needs certain external data to work i.e. particle motion etc....). Even if lwsn was the demon itself, it still would not know that a 3rd party plugin requires some external data file (I think Stealthnet tried to cope with that problem, and handled it most of the time, but in a LAN server based rendering is faster... fact !).
That small "transfer the data" line is full of caveats that the current implementation gracefully circumvents. It would basically require a massive change in the rendering architecture of LW, including 3rd party plugin interfaces (but, on the other hand, could then also bring features like "lazy" loading of objects and images during a render...).

>>As well, your system is proof that SN is not easy to use, nor inherently flexible without writing custom scripts and bolting third party stuff onto it.

The custom script is just because I'm lazy (I co-wrote it, but, to be honest, I hardly ever use it...)

"Bolting third party stuff" is a license for Spider, which, I agree, is not that cheap but worth it (It's a time versus money thing, there is freeware out there..., I / we try to make a living using LW, so the time vs. money thing is important).

>>It takes longer, and costs more money to do something with robustness and flexibilty, but your support costs drop down the road, and considering that the rule of tech support states that after your third support call, any profit from a sale is gone, you would think that this would be a no brainer.

I think NT should scrap the free render node thing alltogether, make lwsn and lightwave .rib compatible (Lightwave writing RIBs as an option, and lwsn rendering RIBs as an option) and sell the render nodes as a stand alone solution with a decent render manager (I bet all those cheap maya and houdini users would love that idea). Honestly, I do.

I assume that currently there are around 10 people developing / programming on the LW front in-house at NT (just a guess). There are plenty of other issues with LW that are of an imho higher priority that the dev team should concentrate on (after all, in a way they work for all of us, don't they ? We pay them ... ).

If people aren't satisfied with the way LW currently handles network rendering, let them pay 3rd parties for a controller, or let NT charge for a souped up solution. Priority wise, I'd rather see: More procedurality across the whole package, tighter Modeler / Layout integration, a much deeper SDK, tight integration of soft/hard bodies, openGL improvements, workflow improvements et al. Tons of stuff...
Tons of stuff that can only be handled by the in-house team since they have the source and they provide the architecture.

If I look at how much time I spend with LW, I spend 99% of my time with the two major apps, and 1% of my time sending scenes to my renderfarm (which usually does 24/7/12 on 10 CPUs). I'd like to spend my time more productively in those 99%.

If, however (like I stated before), the network rendering integrates really tight into Layout (i.e. Viper previews across the network, which affects my 99% of time), then I'd like to see changes in SN, but then I'd like to see big changes and yes, I'd pay for them.

Wow, huge post, I hope I'm not out of line here and excuse the spelling. But this is kind of refreshing, can't wait to hear from you John.

Cheers from Germany,

Michael

By John C. Welch (Jcwelch) (66.189.8.109) on Sunday, April 21, 2002 - 07:23 pm:

>>I'm talking about what happens when a connection maintained and managed by the OS goes wonky. On Winders, it's real fun to watch.

So you want them to circumvent as many OS functions as possible, since there may be bugs and issues in the OS? In that case (I'm going over the top here, but I'm trying to bring my point across, so please excuse...), NT might as well sell Lightwave machines that run nothing else They could just as well (and for the same reasons), write their own 3D acceleration (openGL could be flaky), window management, memory management (which they had massive problems with during the first releases of LW for Win32 if I remeber correctly) and even only use direct low level disk accesses to load and save scenes and objects. Can't really trust an OS, can you]

Nice strawman, but I'm not saying that at all. There are hundreds of nice documented APIs for doing what I'm talking about on any platform. RPC and Sockets are stable, well - understood and tested. If, like other tools of this nature, they need as many CPU cycles for the rendering, then why give one more than necessary to keep a high-level connection open?

[>>Quite honestly, I'm glad to know how NT is not handling this, so when it becomes an issue on my networks, I can make sure that any SN rendering is completely detached from the rest of the network.

Well, once SN rendering becomes an issue on your network, you'll probably need to scrap the whole network and rebuild it I'm mean, a network that doesn't even cater for simple file / volume sharing, what's that? That is just about the only reason why most facilities I know in the post world run a network in the first place, file sharing and centralized storage on a server. And compared to that i/o strain, the question of how SN controls the nodes is a non-issue bandwidth wise. ]

Again, nice try. But what i don't want is open filesharing of critical data at that level with no way to secure it outside of users and groups. Quite honestly, the way NT doesn't implement this is really unimpressive. All that time to create a world-class renderer, and what looks like five minutes for SN. Almost like the lack of work in the SMB client built into Mac OS X. When I'm setting up a system that is requiring user - level connections for something that doesn't need it, and the only logical reason is the convenience of the programmers, not the users, that's not a good thing.

[I brought up the P2P thing because this thread had something to do with clustering, and when I start a render of a scene from my workstation, and my workstation (or any workstation for that matter) starts sending around scene data to render nodes (as opposed to nodes getting their data from the server), then that's P2P to me. ]

Well, with SN as it stands, you don't have a prayer of doing anything more advanced or even different. NT has painted themselves into a corner with the lack of flexibility that rendering over filesharing creates.

[>>UNC connections are manual user-level mounts, don't kid yourself.

True, but the user does not explicitly need to mount them for the OS to access them. Spider for example runs as a service on NT, and can even network render when no user is logged on, without any intervention on the rendering machine by a user. ]

Um...you have to manually create the UNC paths somewhere. The paths act as user level mounts once you enter them. Logged on or not, a user - level connection is a user level connection.

At least your post indicates that NT tried at least once to do it the correct way. Too bad they gave it up.

john

By Ladd Ehlinger (Lehlinger) (206.166.224.226) on Tuesday, February 11, 2003 - 06:44 pm:

This is a very long topic! On the portion relating to the Mac vs PC thing on clustering, I can tell you what we've done with 200 computers. All PC, going through Linux machines clustered to be seen as one server, so that the server isn't overwhelmed. We wrapped LWSN within our own software. Had to be done. Anyway if you're interested in seeing the farm doing it's thing its available for anyone 24 hours a day seven days a week

http://www.respower.com