sunday, holiday, -- what long weekend?

...saturday was all about the long awaited musical festivity unleashed upon the body corporate. after the unnecessary chaos of the bus transfer arrangement to the venue, the entire affair was, to put it mildly, good.

naturally, there were cringe-worthy moments, such as the second of the two special numbers that started the show, but that bears further discussion at a later time...

being somewhat delayed in my self-imposed deadline to fold all the g5 macintoshes into the glories of render slavery, i decided to go to work on sunday. figured that with the editorial crew (who use the machines) having their well-deserved sunday off (seeing as they did production assistance stuff in the run up to the show), i would have a better shot at finally configuring the g5s for their expanded role as render machines. so, checklist in hand (mental and otherwise), arrived at work about 3-ish in the afternoon.

an officemate decided to join me at work and set about investigating the animation complexities of an inverse-kinematic-based hair setup rig.

leaving him to it, i trudged away at the mac configurations, following all the steps, making sure that required directories were made, and various sundry settings input and verified.

it might just be me, but the mac interface and that benighted single button mouse are doing me no favors insofar as getting the work done quickly. granted i may just be more used to the three button logitech wheel mice that 'infest' our side of the floor, but for the life of me, i can't imagine how anyone would live through ctrl-alt-flower-single-click when a simple right mouse click would suffice (and quicker, too) for options.

so: three servers mounted to the root filesystem of the macintosh primary hard disk (analogous to the mapping methods employed on the linux render boxes) -- all in an attempt to more or less standardize the directory relationships across three different operating systems so that our render mongrel system can get its job done.

...and those three servers are not homogenous either. two intel boxes on red hat 9 linux, and one all-conquering dual g5 xserve running the server version of os x. now, that last part is a mouthful, but is actually a quite accurate way of describing that hardware/software combo.

which brings me back to the permission conundrum that had us backtracking off the original g4 xserve and hastily back to the old linux server. everything had been tried, permissions relaxed everywhere, and still our render system would not work.

this time around, we set about making sure the win2k boxes would work well with the xserve. then we moved on the render management system -- and that seemed to have been resolved by deactivating a key security component of os x server, something called 'light directory access protocol'. the troubleshooter noted that 'ldap' was looking to be the future of server permission management, but at this point in time with a deadline looming large, there was no point in trying to figure it out. so he disabled it. lo and behold, the render management system actually began to proceed beyond login failures.

it moved on to render failures.

wonderful.

and so it came to pass that i was logged in remotely on one of the linux boxes and i finally noticed the render system log mentioning that the mounted filesystems from the xserve were read only.

after some web research, found a way to get some info out of the xserve as far as how it was handling nfs (network file system) shares -- the primary method by which we access the servers from the linux/mac boxes. and yes, indeed, there was a switch in the options that was wonderful in its simplicity. the line read:

opts='ro'

hmm. web research showed that by default, it ought to be 'rw'.

ah, except that the example given was set to 'ro' with the note that by default, it ought to be 'rw'.

perhaps the troubleshooter in his haste had overlooked the note.

well, pointed this out to him saturday morning, and he went to the NOC forthwith and removed the offending option.

...but the time had arrived for the exodus to the musical extravaganza venue.

back to the tale at hand: g5s configured, i launched duplicate renders on all the farm and all the macs, and to make matters more colorful, threw in a 65GB copy from a linux server to the xserve where all the rendering machines were reading and writing to.

thence home, after dinner at italianni's. at some point in the dinner with the officemate (who by this time had resigned the attempt to come to terms with the hair rig) -- a frog keychain was placed on the table, together with a little laminated calling card.

the suspect swiftly moved elsewhere, the expected spiel not forthcoming.

i looked at the card, and it read (according to my dim memory)

i am deaf
...
...
...
if you are noble, you will purchase this ... for a hundred pesos

hm. so i am now the proud owner of a frog flashlight that bestows nobility.

---

and today, monday, i finally have some performance figures for the troubleshooter and the higher-ups in technical support. compared to a single dual-proc g5 rendering to a linux server, the xserve improves render performance by at least 10%. that's good. however, it appears to slow down the performance of the linux render farm, however slightly (about 5 minutes in 3 hours).

have to look at that closely.

so no sunday, no holiday; at least i have the frog of nobility.