The Pi Zero Mathematica Dongle

[ejolson]

See the post later in this thread for the final solution.

I thought it might be nice to have a Pi Zero W that I could plug into any computer like a dongle using the USB port and run Mathematica seamlessly in a window on the host computer. First I enabled WiFi on the Zero. Second, I configured the Zero for USB Ethernet gadget mode with 192.168.7.1 as a static IP address. Finally, I configured a DHCP server on the Zero to provide an address in the same subnet to the host computer. This worked well.

Thus encouraged, I downloaded the latest version of xpra, which is a multi-platform seamless remote display server and client. I installed from source because the version included with Raspbian was too old to function reliably. Note that there are up-to-date binaries available for Windows, Mac OSX and x86 Linux. I chose a PC running Debian linux for the host computer and again installed xpra.

To use Mathematica, connect the Zero through a USB cable, wait for the host to acquire an IP number from the DHCP server, then log into the Zero and run

$ xpra start :12 --start-child=mathematica --bind-tcp=0.0.0.0:10000

Finally, return to the host computer and type

$ xpra attach tcp:192.168.7.1:10000

Note that since all communications are running point to point over a directly attached USB cable there is no need to encrypt the connection. After some time, the remote Mathematica window from the Zero will appear among the local windows running on the host computer. It was possible to integrate, differentiate, draw a 2-dimensional graph and plot a 3-dimensional surface.

During this time swap reached about 22MB on the Zero while xpra used from 15 to 50 percent of the CPU. On a well provisioned system xpra is supposed to be faster than tunneling X through ssh; however, both options seem slow in this case. Maybe the future will bring a faster Zero that can still be back-powered through the data port like a USB dongle.

[mattmiller]

I like the idea of static ip and running a DHCP server

But why not just use VNC to remote into the Pi - whats the advantage of faffing with this xpra stuff?

[ejolson]

But why not just use VNC to remote into the Pi - whats the advantage of faffing with this xpra stuff?

As far as I know VNC exports the whole Raspbian desktop, whereas xpra only exports the Mathematica window which then appears as just another application running alongside the local windows on the host computer.

I could be wrong about VNC. Is it possible to export only the Mathematica window and not the rest of the Raspbian desktop?

[mattmiller]

whereas xpra only exports the Mathematica window which then appears as just another application running alongside the local windows on the host computer.

fair enough

[B.Goode]

I downloaded the latest version of xpra, which is a multi-platform seamless remote display server and client.

Thanks for bringing xpra to my attention.

I routinely access my headless RPis with ssh -X (or its equivalent in the PuTTY windows app) in conjunction with a standalone X-windows server such as XMing, but it is always useful to know of viable alternatives.

As with your example, I rarely need access to the whole RPF Desktop, but just want to run individual X-windows client applications.

I'll be giving xpra a trial run.

[n67]

I'll be giving xpra a trial run.

xpra is a *BEAR* to compile. I spent most of an afternoon trying - and eventually gave up in disgust.

As OP notes, there is a version in the repos, but it is old and doesn't work. Correction; It works, but very, very slowly. So, don't even bother with that version.

The problem is that xpra requires CPython (whatever that is) and CPython isn't there by default (note: It may be there now, it wasn't when I tried this). Getting CPython installed and working is a known deep, dark hole. When I tried to get it installed, it spent an entire afternoon repeatedly re-compiling itself. Weird.


Back to the original question of "Why xpra?": First of all, xpra bills itself as "screen for X" - i.e., a way to have an X session going, that survives network disconnects. But, as noted in this thread, VNC does that too, so I don't really think there's any point to xpra (though I'd still be interested in trying it out, if it can be compiled). However, you want to use VNC in the "create a new session for me" mode, not the "MIrror the HDMI display" mode. That's the key. You will want to customize the newly created session to be running as little extra cruft as possible - you certainly don't need the regular "Raspbian Desktop with Pixel and everything else" desktop (Yes, I know Pixel is a word we're not supposed to use anymore, but let's let that pass...).

Now, as noted in the OP, it is true that the "normal" method of getting X is to "tunnel" it through "ssh". But, as OP notes, this is slow for any non-trivial graphical application (most people just use it for basic stuff - a few Xterms, maybe a clock...) So, OP is right to be seeking an alternative to ssh. In the next paragraph, I will describe an alternative that I think OP might be interested in trying.

The problem with ssh seems to be the encryption, which slows things down. In situations such as the subject matter of this thread, encryption is an unnecessary distraction. So, I suggest using "socat" (which is just an apt-get away). The following command will allow other machines to connect to your local X server by setting their DISPLAY to <yourIP>:1

Code: Select all

$ socat TCP-LISTEN:6001,fork,reuseaddr unix-connect:/tmp/.X11-unix/X0 &
$

Note that, in fact, using socat this way is just a workaround for the fact that modern X invocations on Linux systems include the option "-nolisten tcp" - which disables accessing the X server over the network. They do this for some dumb "security" reason. socat allows us to put back this functionality.

It's all safe enough, provided you're behind a router/firewall, and you trust your family members.

There may be options in socat and/or xhost to tighten this up if needed, but I've never delved into it.

[ejolson]

Getting CPython installed and working is a known deep, dark hole.

It appears Cython is a way to speed the original Python code up. Another speed improvement in recent versions of xpra comes from using rencode for packet encoding rather than bencode. To install Cython I used

# apt-get install cython

This installed version 0.25.2 which seemed good enough for compiling xpra. Since I started with Raspbian Stretch Lite I also needed to install the package python-rencode and a bunch of other stuff.

The idea of using unencrypted X forwarding seems reasonable because it saves memory on the Zero. On the host computer I first typed

$ ifconfig usb0
$ echo $DISPLAY
$ xhost +192.168.7.1

Then on the Pi Zero type

$ export DISPLAY=192.168.7.3:3
$ mathematica &

where 192.168.7.3 is the IP number of the host found by ifconfig above and :3 is the X display number of the host found by the echo. Again, no encryption is needed because we are communicating to the Zero over a point-to-point USB cable.

Even without encryption, the way Mathematica talks the X network protocol is so inefficient that the xpra method still worked better.

It is likely RealVNC will perform the best. I just need to figure out a way for it to start Mathematica without all that extra Raspbian desktop stuff.

[n67]

You never specified what your "host computer" was/is. For my purposes, I assumed another Pi - or some other reasonably modern Linux install - in which case, you can't do it without either using socat (or something like it) or hacking the system to disable the "-nolisten" bug.

It sounds like your "host computer" is Windows, running some 3rd party X server (maybe MobyXTerm?), in which TCP listening isn't disabled.

Anyway, yes, using a "newly created" session in RealVNC is probably the way to go. As I said, you'll want to disable as much cruft as you can.

[B.Goode]

It appears Cython is a way to speed the original Python code up. Another speed improvement in recent versions of xpra comes from using rencode for packet encoding rather than bencode. To install Cython I used

# apt-get install cython

This installed version 0.25.2 which seemed good enough for compiling xpra. Since I started with Raspbian Stretch Lite I also needed to install the package python-rencode and a bunch of other stuff.

Thanks for that.

Apart from dependencies - I can usually cope with those - are there any other tips/wrinkles/hints you can give for building xpra for Raspbian?

Did you start from a source tarball like https://xpra.org/src/xpra-2.2.6.tar.xz

[ejolson]

You never specified what your "host computer" was/is.

The host computer is a PC running Linux. More specifically, 64-bit Debian Jessie using the fvwm window manager configured without dbus or systemd. I didn't know that an automatically configured firewall needs to be disabled otherwise.

At any rate, Mathematica seems to rely on a windowing toolkit that does not efficiently forward over the X network protocol. Do you have any tips for setting up RealVNC?

[ejolson]

Did you start from a source tarball like https://xpra.org/src/xpra-2.2.6.tar.xz

Yes, that's the version I installed. The main thing I did when building was to disable the html5 client. I have notes and can post them. I didn't already because performance is still slow. Also, I'm getting a systemd error on startup that needs to go away.

[B.Goode]

Do you have any tips for setting up RealVNC?

You've probably found the RPF documentation here:
https://www.raspberrypi.org/documentati ... /README.md

I've never put any effort into seeing if it can handle a particular client app rather than the Desktop. (In principle the Desktop is just an instance of a rather special x-11 client app so it might be trivial... )

[ejolson]

However, you want to use VNC in the "create a new session for me" mode, not the "MIrror the HDMI display" mode.

For efficiency, wouldn't it be better to export the HDMI screen? Presumably this would allow Mathematica to leverage the 2 and 3-dimensional acceleration in the hardware video driver. Is this correct?

[ejolson]

Here is an update on using realvnc-vnc-server for the Pi Zero Mathematica Dongle. The result so far is that RealVNC appears faster in virtual mode than either xpra or running X directly over the network. Aside from the 3D graphics, it is usable. I would like to try vncserver-x11 in the raspi screen capture mode to see if it makes a difference for 3D performance. Any suggestions how to do this, aside from starting over with a full Raspbian image, would be appreciated.

[ejolson]

I now have Mathematica running on the physical screen. The solution was to disable Xorg.wrap by renaming it is as

# cd /usr/lib/xorg
# mv Xorg.wrap Xorg.wrap-bad
# chmod 6755 Xorg

This allows people who are not logged into the console to start an Xserver displaying on the hardware frame buffer. Next, I changed the frame-buffer resolution in /boot/config.txt to

framebuffer_width=800
framebuffer_height=1000
gpu_mem=128

so I get a reasonably sized window on my desktop with VNC later. Note that I also increased the video RAM split as recommended on the RealVNC website for directly exporting the frame buffer. This may not be necessary, and definitely goes against the idea that Mathematica needs more memory, but never mind that for now. Finally, I added the lines

CaptureTech=raspi
ExperimentalRaspiCapture=1
ServerPreferredEncoding=JPEG

to ~/.vnc/config.d/vncserver-x11 in order to turn on GPU screen capture as when running Minecraft. Now reboot the Pi Zero so the changes to config.txt take effect.

To start Mathematica, log in through ssh to the Pi Zero and type

$ xinit &
$ DISPLAY=:0 vncserver-x11 &

Then return to the host computer and connect to 192.168.7.1 using the vncviewer.

It is difficult to tell whether Mathematica is working faster or not. Three dimensional rendering of surfaces given by a command such as

Plot3D[Sin[x+y^2],{x,-3,3},{y,-2,2}]

is still not possible to rotate in a pleasing way using the mouse. From this point of view, using the physical frame buffer seems worse than switching the gpu_mem split to the minimum and using vncserver-virtual. Before deciding on the final configuration, it makes sense to finish by comparing the xorgrdp server.

[ejolson]

Earlier in this thread I used xpra to make a window running Mathematica from the Zero appear directly among the local windows on the host computer. Since the version of xpra that ships with Raspbian is old, I installed a new version of xpra from source. While this looked great, it resulted in more computational overhead than when using RealVNC. I planned to try with xorgrdp. However, this is again a situation where an install from source is necessary for a valid comparison. Having other things to do, I've decided to skip that step and go with what is working now. Here is my final method for making a Mathematica USB dongle.

Download a copy of full Raspbian 2018-04-18-raspbian-stretch.zip unzip it and copy it to a new SD card. I used an 8GB card--larger ones are fine. Mount the DOS partition of the card, also known as the boot partition. To the end of config.txt add

dtoverlay=dwc2
framebuffer_width=1280
framebuffer_height=1024

Since the Zero will be running headless, we need to specify the default size of the video frame buffer, otherwise the resulting desktop will be very tiny. Since I have a 1920x1200 resolution monitor on my host computer, setting a size of 1280x1024 yields a reasonable window into the Zero later. As far as I can tell, many different dimensions will work, though it is possible that odd sizes may affect hardware acceleration later.

Next change cmdline.txt to

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether g_ether.host_addr=02:46:c0:a8:0d:02 g_ether.dev_addr=02:46:c0:a8:0d:01 quiet init=/usr/lib/raspi-config/init_resize.sh splash plymouth.ignore-serial-consoles

Note that the above file consists of only one very long line. Create an empty file in /boot called ssh to enable secure login

$ touch ssh

and further a file called wpa_supplicant.conf that will be automatically copied to the main partition upon booting that contains

Code: Select all

country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="your_real_wifi_ssid"
    scan_ssid=1
    key_mgmt=WPA-PSK
    psk="your_real_password"
}

Unmount the SD card, place it in the Zero W and then boot it by plugging it in to the USB port of the PC which will serve as the host computer. Upon first boot, the Zero will expand the root filesystem to fill the SD card, create a swap file, enable secure login, switch the USB port to device mode, load the gadget driver and connect to WiFi. Although we will connect through USB momentarily it is easiest to log in first through WiFi and perform some additional configuration. To do this, check the DHCP lease table in your WiFi router. Mine looks like



which indicates that my Pi is on 192.168.46.138. Connect using any secure shell client such as putty on Windows or slogin on Mac or Linux. I'm using a Linux PC as the host computer so I'll type

$ slogin 192.168.46.138 -l pi

with the default password of raspberry to log in. The first thing to do is change the password with the command

pi@raspberrypi:~ $ passwd

note that this step should not be done using a public WiFi because the default password is well known and you will also need access to the router to figure out the actual IP number that was assigned to the Zero.

There is an alternative method to configure things in which first-time login is through the USB connection. This other method requires either editing files on partition two of the SD card which is Linux format using another Pi computer, or installing the Bonjour protocol on the host computer in order to make the initial connection to the Pi. I will not discuss these alternatives further here.

Procede by finishing the configuration of the USB gadget driver. First install some software with

pi@raspberrypi:~ $ sudo bash
root@raspberrypi:/home/pi# apt-get update
root@raspberrypi:/home/pi# apt-get install isc-dhcp-server

You will get a bunch of systemd startup failure messages. Failure seems to be the expected mode of operation for systemd and comes from the fact that we haven't actually had time to configure the dhcp server. Let's do that now first editing the file /etc/default/isc-dhcp-server and changing the INTERFACESv4 line to read

INTERFACESv4="usb0"

Then move the default /etc/dhcp/dhcpd.conf out of the way and create a new one which contains exactly the lines

Code: Select all

ddns-update-style none;
subnet 192.168.13.0 netmask 255.255.255.0 {
        range 192.168.13.128 192.168.13.254;
}
host garden {
    hardware ethernet 02:46:c0:a8:0d:02;
    fixed-address 192.168.13.2;
}

The above file consists of two rules: The first rule assigns any computer at the other end of the USB cable an IP number in the 192.168.13.x subnet. The second rule specifically assigns the number 192.168.13.2 to MAC address 02:46:c0:a8:0d:02 which is supposed to be the other end of the USB cable. While the second rule should be enough, there appears to be an issue with USB gadget driver where it sometimes mixes up the MAC addresses. Having both rules allows things work in either case. If anyone has a solution that fixes this problem, I think many people would be interested.

Now configure the USB gadget to assign a static IP address to the Zero end of the cable. This is done by creating the file /etc/network/interfaces.d/usbgadget which contains the following

Code: Select all

allow-hotplug usb0
iface usb0 inet static
    address 192.168.13.1
    netmask 255.255.255.0

and then editing /etc/dhcpcd.conf to add the line

denyinterfaces usb0

at the top to prevent a race between the two network configuration tools. Be careful not to get the similarly named dhcpcd.conf and dhcpd.conf files mixed up. At this point we can reboot the Pi Zero and obtain a properly configured USB connection. Reboot using the command

root@raspberrypi:~# reboot

In less than a minute the Zero should be up and running. It will now be possible to log in through the direct USB connection. Check the host computer to see if a USB Ethernet device is present and whether it has been assigned an IP number. If it does not have an IP number, you may have to click with your mouse to enable DHCP on it. On my Linux PC I can type the command

Code: Select all

# dhclient usb0
# ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 02:46:c0:a8:0d:02  
          inet addr:192.168.13.2  Bcast:192.168.13.255  Mask:255.255.255.0
          inet6 addr: fe80::46:c0ff:fea8:d02/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:656 (656.0 B)  TX bytes:7627 (7.4 KiB)

to obtain a lease. Connect to the Pi using secure login with the address 192.168.13.1. For example

$ slogin 192.168.13.1 -l pi

Don't forget to use the new password that you created earlier. At this point it is reasonable to check that the hardware is working properly. For example, if you are using a bad cable or connecting though an old hub, you might end up with a full-speed 12Mbps connection rather than a high-speed 480Mbps one. To check the USB network speed install iperf3 on the Raspberry Pi and the host computer. On the Zero type

pi@raspberrypi:~ $ sudo apt-get install iperf3
pi@raspberrypi:~ $ iperf3 -s

On the host computer do something similar and finally type

$ iperf3 -c 192.168.13.1

Output from a misconfigured USB connection will look like

Code: Select all

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  6.21 MBytes  5.21 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  6.19 MBytes  5.19 Mbits/sec                  receiver

which is super slow. If this is the case, shutdown the Pi using the command

pi@raspberrypi:~ $ sudo shutdown now

wait for the green light to blink four times, remain steady and then go out. Now plug your Pi Zero dongle into a high-speed port and try again. Note that if you had to start dhclient manually, you will have to stop and start it again to obtain a new DHCP lease after the Zero reboots. Most PCs offer continuous power to their USB ports while plugged in. It is therefore also possible to reboot the host computer while the Zero is running. If you are having trouble getting high speed this may help.

For my PC in particular, if the Zero is the only USB device connected and I reboot the Pi, then the USB port gets stuck in full speed mode. Rebooting the PC while leaving the Pi running immediately switches to the correct high speed mode. On the other hand, if there other high speed devices already connected then there are no problems either way.

Output from a correctly configured USB connection will look like

Code: Select all

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   173 MBytes   145 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   173 MBytes   145 Mbits/sec                  receiver

The resulting bandwidth is greater than a 100 Mbit Ethernet connection but slower than the 1Gbit wired networking on the new Pi 3B+. As a point of comparison it is interesting to compare these results with WiFi. Since WiFi is a broadcast medium, its speed depends on how many other WiFi devices are active within range of the radio transmitter and receiver. In my case, testing the WiFi connection yields

Code: Select all

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  5.83 MBytes  4.89 Mbits/sec    5             sender
[  4]   0.00-10.00  sec  5.78 MBytes  4.85 Mbits/sec                  receiver

which is even slower than the incorrectly configured USB cable. Note also that there were 5 retransmissions during the test, which indicates a few packets were lost due to radio interference. As an aside, the above numbers indicate why building an OctaPi using WiFi is less effective than building one using wired networking. What remains is to set up RealVNC to allow running Mathematica in a window on the host computer.

From this point on we can follow the documentation from the Raspberry Pi Foundation and from RealVNC. RealVNC is already installed on the Zero; however, it needs to be enabled. Log into the Zero and type

pi@raspberrypi:~ $ sudo raspi-config

then select Interfacing Options -> VNC -> Yes. Then, exit the program.

RealVNC may not already be installed on the host computer. Fortunately, the needed RealVNC viewer is a free download for Windows, Mac OS/X and Linux as well other commercial Unix systems and even cell phones. Download the correct version for your host computer. It is now possible to connect to the graphical desktop of the Zero through the USB cable.

Start vncviewer on the host computer. Click on File -> New Connection and fill out the form as indicated



click OK after which an icon labeled raspberrypi should appear in the VNC viewer window. It is fine to disable encryption because all communication is already private using a point-to-point connection over the USB cable. Now double-click on the icon in the viewer, click Continue, set the user name to pi, enter the password for the Zero and click OK. After a moment the full Raspbian desktop will appear exported from the Raspberry Pi to the screen of the host computer. Start Mathematica and you're done.

[ejolson]

For my PC in particular, if the Zero is the only USB device connected and I reboot the Pi, then the USB port gets stuck in full speed mode.

The solution to this problem appears to be place

dwc_otg.speed=2

as an additional option on cmdline.txt to force USB 2 high-speed mode. More information may be found in this post which describes setting up a Pi Zero to boot without an SD card using Microsoft Windows.