Success Through a Failed Attempt to Set up an Xserver Environment

When you rsh into a raspberry Pi, the splash screen includes the following line:

   Type 'startx' to launch a graphical session

I've logged into headless machines before and set up the DISPLAY variable so that I could start an Xserver and have all of the graphical output directed to a machine with a real display device.  This is pretty vanilla Unix stuff, but it led to some other mildly interesting discoveries about my particular VM-based environment.

When I did an ifconfig, it revealed that my IP address was 192.168.91.143.  I was on a different subnet than the rest of my network.  I could ping my Ubuntu guest in at this IP address from my Windows 7 base environment, but the response times were very sluggish - ranging from 500 MS to well over a second.  Nothing actually timed out, but it wasn't optimal.  I could also ping my PIs from Windows 7, and things there seemed pretty normal.

For some reason though, I couldn't reach my Ubuntu guest from the PIs.  This means that I wouldn't be able to use this guess as an X client, and have it receive graphical sessions from the PIs.  Why I could go the other direction from Ubuntu to the PIs is beyond me.  There are network details here that I don't understand, and don't really plan to find out.

It then occurred to me that these behaviors are probably the result of the default network connection that VMware and most other give you - Network Address Translation (NAT).  This maps the IP address of the guest system to the underlying IP address of the host machine so that they share an IP address as far as the external network sees them.  Presumably this means that somewhere in the stack, my 192.168.91.143 address that Ubuntu sees, gets mapped to the 192.168.1.102 address of my Windows 7 environment.  All of this address translation is probably why performance suffers when I Ping Ubuntu from Windows.

I tried switching to a bridged configuration to see what would happen.  I've had bad experiences with this in the past under KVM and VirtualBox - both of which not only didn't work properly, but they left my guest system flopping around like a fish out of water.

This time however, everything worked as I had expected.  My IP address changed to 192.168.1.118, so I was on the same subnet as everyone else.  I could reach my Guest system from the PIs, and the apparent performance issues I had between Windows and Ubuntu vanished.  VMware was solid here, and life is good - almost.

I exported my DISPLAY variable from one of the PIs to my new Ubuntu IP address, and attempted to start an Xserver via startx.  It still didn't work.  At this point, I've decided to put this effort on the shelf.  It isn't strictly needed for what I want to do right now.  This exercise was a fruitful one though, because I'm not running a bridged connection that I think will give me more of what I want in terms of performance and configuration.

I'll be back to this later though.

Back to Bramble Setup

Ok, class finished about a week ago, and it was a great experience.  I'm looking forward to taking another course in the future, but for now it's time to get back to the Pi bramble.  Once I get the setup completed, there are some interesting things that I'm going to try to drag over from my Neural Networks environment to the bramble.

Just to level-set, I've got the message passing interface (mpich2) installed and built on all of the Pi machines.  I see that there is now an mpich version 3 available as of mid-November, but I'm staying put on this version until we get things up and running.

The next step is now to configure the network of machines.  I established machine number 1 as the master, and the rest as slave machines.  Follow the directions to setup the rhosts files for the root and pi users, and /etc/hosts so that all of the machines can see each other by name (see the instructions in the west coast labs blog).  My /etc/hosts on each machine now contains these lines (among others):

192.168.1.151    RsPi1    RsPi_1    R1    r1    Master     master
192.168.1.152    RsPi2    RsPi_2    R2    r2    SlaveR2    slaver2    slave2
192.168.1.153    RsPi3    RsPi_3    R3    r3    SlaveR3    slaver3    slave3
192.168.1.154    RsPi4    RsPi_4    R4    r4    SlaveR4    slaver4    slave4
192.168.1.155    RsPi5    RsPi_5    R5    r5    SlaveR5    slaver5    slave5
192.168.1.156    RsPi6    RsPi_6    R6    r6    SlaveR6    slaver6    slave6
192.168.1.157    RsPi7    RsPi_7    R7    r7    Slaver7    slaver7    slave7
192.168.1.158    RsPi8    RsPi_8    R8    r8    Slaver8    slaver8    slave8

This is replicated on all of the Pi machines.  It's as far as I've been able to get with the setup so far.  I'm getting close to running something soon.