[Beowulf] PVM on wireless...
Robert G. Brown
rgb at phy.duke.edu
Fri Feb 8 08:40:50 PST 2008
On Fri, 8 Feb 2008, kohlja at ornl.gov wrote:
> Awesome Strangelove Reference...! :-D
>
> "I Have A Plan...!" :-)
>
> Yep, I am now getting inundated with people having rsh/ssh problems
> with PVM, so a higher power clearly wants me to better document this.
>
> Thanks Much, Will Do... :)
Excellentamundo! At some point at your convenience in the future when
you have all kinds of time to metaphorically sit down and REALLY work
over PVM, I have about 800 specific suggestions for bringing it up to
current and modern and everything. Just a wee list. You know:
* Purge aimk for all time, die die die
* Actually use the FSH so e.g. apropos pvm works.
* Document the hell out of everything
* Rewrite the network back end in a way that openly encourages high
end network vendors to contribute reusable non-IP native drivers
* Add a (possibly macro-driven) middle layer that makes PVM into MPI
as well -- one set of actual message-passing functions, two conformally
mapped call interfaces.
* Make Ctrl-C work so one can break out of the annoying timeout on add
hosts when things don't work.
* Make the console capable of cleaning up after a crash or
interruption.
that kind of thing...;-)
rgb
>
> Jeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeem ;)
>
> On Fri, Feb 08, 2008 at 05:35:31AM -0500, Robert G. Brown wrote:
> > On Thu, 7 Feb 2008, kohlja at ornl.gov wrote:
>
> >> I admit this may be an antiquated cynical mentality, and I
> >> further concur that PVMNETSOCKPORT is an obvious omission
> >> in the basic documentation/faq...
>
> > As they say, you can't RTFM if there ain't no FM... (or if the solution
> > exists but isn't there).
>
> > One is reminded of Dr. Strangelove, where the president (Peter Sellers)
> > has just learned that if the maverick B52 piloted by Slim Pickens gets
> > through, a doomsday device that is supposed to deter first nuclear
> > strikes will go off that will destroy the world. Unfortunately, the
> > Soviet Union didn't actually tell us that it was built. Dr.
> > Strangelove (Peter Sellers), after musing for a moment on the brilliance
> > of the concept, turns and says in an increasingly shrill voice:
>
> > But...the whole point of the Doomsday Machine...is lost...if you keep
> > it a SECRET. Why didn't you tell the world, eh?
>
> > Hmmm...;-)
>
> > rgb
>
> >> Thanks for your suggested text! (And the suggestion to
> >> enhance our coverage of rsh/ssh usage... :-)
>
> > Ya, well. Just now finished telling the umptieth would-be PVM user how
> > to go about it in an email message, augmenting further online docs such
> > as this one:
>
> > http://www.uow.edu.au/~suresh/web/cfamily/pvm.html
>
> > which is actually pretty decent, although I generally use the ssh
> > default dsa instead of rsa since on linux boxes it invariably works.
> > But better than forcing each user to employ google to snarf out
> > solutions to each problem they encounter, how much better to write a
> > really nice "Getting Started with PVM" or perhaps better still, a "PVM
> > HOWTO" on tldp.org. Publish there, and be sure to include a copy in
> > plain sight in /usr/share/pvm3/PVM_HOWTO.
>
> > Truthfully, good documentation, especially a walkthrough tutorial on
> > getting started (including sample code or links to sample code) that
> > takes a would-be user from "yum install pvm\*" to executing a Real
> > Parallel Program (however trivial) on a two node cluster would really
> > encourage the use of the library. Adding a bit more (such as a PVM
> > program development template) would be only icing on the cake, so to
> > speak.
>
> > If I had the time I'd write it myself. I've already got a project_pvm
> > program template up on the web, but it is sadly underdocumented through
> > the setup of PVM itself.
>
> > rgb
>
> >>
> >> All the Best,
> >>
> >> Jeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeem ;)
> >>
> >> On Thu, Feb 07, 2008 at 04:42:21PM -0500, Robert G. Brown wrote:
> >> >> > It would really, really help if man pvm (or man pvmd or man
> >> pvm_intro)
> >> >> > documented a suitable firewall setting that will let PVM function
> >> >> > without just turning off the firewall altogether. There is no pvm
> >> >> setup
> >> >> > in /etc/services, for example, no pvm checkbox in the panels
> >> managed by
> >> >> > system-config-firewall in the latest Fedoras, no suggestion as to
> >> what
> >> >> > what protected port(s) or ranges one has to enable explicitly. In
> >> fact
> >> >> > for once even google is failing me -- I'm not finding a lot of
> >> >> > documentation or remarks by ANYONE on what ports pvm needs open
> >> >> (besides
> >> >> > ssh, which obviously is open and works). Usually as long as the
> >> >> > spawning of a network application itself works using an enabled
> >> >> > protected port (in this case, I would have expected ssh), the
> >> secondary
> >> >> > ports opened in unprotected space just work. Am I wrong in this?
> >> Do I
> >> >> > need to explicitly open more ports somewhere?
> >> >>
> >> >> Ah Yes. O.K., so I wish it was that simple, but alas PVM can use as
> >> >> many ports as you have machines in your cluster, or could use just 1.
> >> :-}
> >> >>
> >> >> Normally, the master pvmd creates/accepts connections over a small
> >> >> set of ports, possibly 1, but if PvmRouteDirect is enabled in a PVM
> >> >> application, then a myriad of direct-connection socket links are
> >> >> created, to link whichever machines the local PVM application tasks
> >> >> communicate with, on a demand-driven basis...
> >> >>
> >> >> So it's not generally possible to specify an explicit "range" of
> >> ports.
> >> >> However, it _is_ possible to set the "starting" port for this
> >> collection,
> >> >> using the aforementioned "$PVMNETSOCKPORT" environment variable.
> >>
> >> > OK, I'm giving this a try. Although I'd have to ask why pvmd doesn't
> >> do
> >> > the fork thing and clone a single open port on which it listens into a
> >> > dynamically allocated port that inherits from the open one. In
> >> > principle one only needs a single port to be open to connect to pretty
> >> > much any network based application, or so I had thought. At least, I
> >> do
> >> > that in xmlsysd and never have to punch more than one porthole through
> >> a
> >> > firewall.
> >>
> >> > Hmmm, it's working sort of -- looks like I need to open UPD ports,
> >> > right, not TCP? Having trouble on one host where I've punched the hole
> >> > but didn't >>locally<< set PVMNETSOCKPORT to match, so I'm trying again
> >> > with the local environment variable set.
> >>
> >> > Yup, that works.
> >>
> >> > So I'm guessing that pvmd reads it as it starts up wherever. Why does
> >> > it need to do this on a client? Can't the port(s) be passed from the
> >> > master when it starts up pvmd?
> >>
> >> >> This sets the first port that PVM will try to use, and all subsequent
> >> >> ports will usually be consecutive positive increments of that starting
> >> >> port (i.e. PVMNETSOCKPORT++... :-).
> >> >>
> >> >> So in most cases, you could probably plan on opening up a 100 or 1000
> >> >> ports _somewhere_ in your firewall, depending on your needs, and then
> >> >> just tell PVM where to start, using $PVMNETSOCKPORT...
> >> >>
> >> >> I've always considered this solution a bit of a kludge, which is why
> >> >> it doesn't show up in the man pages, but if it works well enough to
> >> >> save people lots of hassle, then I can add some commentary on it...?
> >>
> >> > Kludge or not, how can you have an environment variable in an
> >> > application and not provide knowledge of it or instructions on its use
> >> > in the man page? Something like:
> >>
> >> > PVM requires open ports on target hosts to function. Many hosts are
> >> > installed with strong firewall rules by default. If you install pvm
> >> on
> >> > a slave and pvm appears to hang when you attempt to add it, eventually
> >> > timing out without success, consider adding the following to your
> >> local
> >> > personal or system environment (in, for example, ~/.bash_profile on
> >> all
> >> > hosts):
> >>
> >> > PVMNETSOCKPORT=10000
> >> > export PVMNETSOCKPORT
> >>
> >> > Then configure your firewall(s) to open a range of udp ports starting
> >> > at this value, such as 10000-11024 (which need be any larger than the
> >> > largest number of machines you expect to have in your virtual
> >> machine).
> >>
> >> > However a better solution still is to have the daemon fork on a single
> >> > "permanent" port address > 1024, e.g. 10000, and get a negotiated
> >> > connection in the upper (non-protected) port space that way.
> >>
> >> >> It may depend on the firewall settings, but a nice "Connection
> >> >> Refused" would usually go a long way toward diagnosing things,
> >> >> whereas the more secure firewall alternative of simply
> >> >> "no response" would only result in a "timed out" PVM message...
> >> >>
> >> >> I'm open to suggestions on ways to identify or diagnose the
> >> problem...!
> >>
> >> > As I said, document EVERYTHING in the man page(s). It is what it is
> >> for.
> >> > Lots of users do, in fact, RTFM but get frustrated and give up when
> >> they
> >> > try something and it just doesn't work and they can't see why.
> >>
> >> > On the same line, a perennial problem with PVM is getting it to work
> >> > with rsh and ssh. In fact, half the problems I help people with who
> >> > randomly write me is getting it to work with one or the other. The
> >> > internal diagnostics are certainly very helpful, at this point, but it
> >> > would also be worth adding a new man page like pvm_rsh that does
> >> nothing
> >> > but walk users through the ritual of setting PVM_RSH and establishing
> >> > appropriate e.g. ssh keys.
> >>
> >> > Just a thought or two.
> >>
> >> > rgb
> >>
> >> >>
> >> >> Thanks Much for your interest and feedback!
> >> >>
> >> >> All the Best,
> >> >>
> >> >> Jeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeem ;)
> >> >>
> >> >> > I actually help a lot of people get started with PVM (they write me
> >> >> > offline because I have a template PVM tarball up on my personal
> >> >> website)
> >> >> > and the more I know, the better I can help them...;-)
> >> >>
> >> >> > rgb
> >> >>
> >> >> > --
> >> >> > Robert G. Brown Phone(cell):
> >> 1-919-280-8443
> >> >> > Duke University Physics Dept, Box 90305
> >> >> > Durham, N.C. 27708-0305
> >> >> > Web: http://www.phy.duke.edu/~rgb
> >> >> > Book of Lilith Website:
> >> http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
> >> >> > Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
> >> >>
> >> >>
> >> (:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:(:
> >> >>
> >> >> James Arthur "Jeeembo" Kohl, Ph.D. "Da Blooos Brathas?! They
> >> >> Oak Ridge National Laboratory still owe you money,
> >> Fool!"
> >> >> kohlja at ornl.gov
> >> >> http://www.csm.ornl.gov/~kohl/ Long Live Curtis Blues!!!
> >> >>
> >> >>
> >> :):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):):)
> >> >>
> >>
> >> > --
> >> > Robert G. Brown Phone(cell): 1-919-280-8443
> >> > Duke University Physics Dept, Box 90305
> >> > Durham, N.C. 27708-0305
> >> > Web: http://www.phy.duke.edu/~rgb
> >> > Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
> >> > Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
> >>
>
> > --
> > Robert G. Brown Phone(cell): 1-919-280-8443
> > Duke University Physics Dept, Box 90305
> > Durham, N.C. 27708-0305
> > Web: http://www.phy.duke.edu/~rgb
> > Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
> > Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>
--
Robert G. Brown Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
More information about the Beowulf
mailing list