NIMBY - Not In My Back Yard
Disabling desktop systems as servers

Intro

The alfred -nimby mode gives users some control over how much remote work reaches their workstation in the typical scenario where interactive users' desktop machines are also being used as rendering/compute servers.

In this mode alfred produces a small desktop UI which indicates, and controls, the availability of the current system as a server. The nimby process contacts the network-wide maitre_d and requests a temporary block on dispatching to any services listed in the master schedule which are on the current host. That is: other alfred users on the network are blocked from sending jobs to the system running nimby because the maitre_d never makes the host available.

If the interactive user is idle for "a long time" then the nimby process will inform the maitre_d that dispatching is allowed. The idle period is determined by the current screen-saver timeout, as indicated by xset(1). When the user returns and causes the system to "wake up" (by moving the mouse, for example), then the nimby process automatically informs the maitre_d to once again block dispatching.

This window is actually a button, click on the window to open the status/control dialog:

This is the default configuration in which dispatching only happens when the user has been idle. In this state the "watch servers" dialog from the regular alfred monitor will show this host as having its "shields raised".

Sometimes it's useful, and socially magnanimous, to allow remote alfred jobs on a system even when it has an interactive user. Selecting the "Always allow remote jobs" mode informs the maitre_d that it can bind this server to remote dispatchers.


Ejecting in-progress tasks

If the maitre_d has allowed remote work onto a nimby-controlled host the owner of the job will be listed in the dialog. Also the elapsed time of the dispatched task will be shown (which might indicate whether it's just beginning or almost done). The nimby UI provides a button for "ejecting" any alfred-dispatched work. When the button is pressed, the maitre_d requests a task-retract from the appropriate dispatcher. The dispatcher does what it can to shut down the client side of the task which generally causes the server side to be shut down as well. The dispatcher will restart the task on another server.

The AutoEject mode interrupts tasks dispatched during idle time (e.g. when the screen-saver is active) automatically when user activity resumes.  

 

 

The Desktop Environment and NIMBY

The nimby process knows how to respond to window manager "save yourself" directives, and therefore cooperates with the saved-desktop mechanism. Typically an interactive user will start alfred -nimby once manually, then its location will be remembered at logout and it will be automatically restarted again on login. The current modes are stored in the ~/.pixarPrefs/nimby.prefs file.

 

To get a minimal alfred -nimby window on the desktop, use the window manager configuration files to remove the usual window controls. In nimby mode alfred sets its X11 instance name to "nimby" so one approach is to place the following line in ~/.Xresources

    *nimby*clientDecoration: none
(hint: to move/reshape the borderless window, when using 4Dwm, press Alt-Spacebar when the mouse is over the window).

 

 

A note about Screen-Savers

If a desktop system is being used as remote rendering/compute server, users should be careful to have low-overhead screensavers enabled, "Blank" being the simplest and lowest overhead. Some of the more exciting screensavers consume enough CPU cycles to make remote computing pointless.
 

Pixar Animation Studios
(510) 752-3000 (voice)   (510) 752-3151 (fax)
Copyright © 1996- Pixar. All rights reserved.
RenderMan® is a registered trademark of Pixar.