Earlier, I had mentioned that it appeared that the individual threads on the Chromebook seemed to be faster than the threads on the 8-core server running at a clock speed over 50% higher. I’ve done the deeper look I suggested then, and I have found something interesting: For the program I used (my Go playing program, michi-go), reducing the number of threads results in each thread doing more work. Michi-go is written in the Go language.
I’ve been quite impressed with the performance of the Chromebook that has become my primary portable system. It is an Acer Chromebook 11 C740. The CPU is a dual-core Celeron 3205U running at a nominal 1.5 GHz. It has 4 GB of RAM and a 256 GB SSD drive. I’m running this system in Developer mode which gives shell access. I’ve created a chroot that is running a current version of Ubuntu.
Not much progress today. The LCD I am using for the display on the head unit requires a mini USB connector. I only have micro USB connectors right now. Getting the initial connection with the new LCD display will have to wait. The USB connector for the ezLCD display I am using provides power, control, and access to storage for fonts and images directly in the display. There is another connector that can be used using direct serial access.
Our ubiquitous data connectivity is a great thing. We don’t appreciate just how useful it is, and how much we depend on it, until we arrive in a place where it does not work. We had an issue with cellular access on our last trip to Canada. This has caused me to think about data connectivity experiences I have ad over the years. Canada (2016) While we were very late in acquiring smartphones, we use this connection all the time.
Decisions, Decisions, Decisions Since a single system image OS is not a viable options, I need to decide what system image to start with. As interesting as Plan 9 is, I think I will wait an look at that one after I have more experience with the capabilities of the more travelled path. I will use a Linux load of some kind. This environment is very efficient and I am very familiar with building and maintaining system using Linux.
While I wait for the replacement cables, I can spend some time thinking about what I will actually do with this portable supercomputer once I have it up and running. To start, the portable supercomputer is a cluster of 4 nodes in a single, small frame with integrated power and internal network. Each node of this cluster is a Raspberry Pi 3 B, so calling it a supercomputer is a bit of a stretch.
Measure Twice; Cut Order Once While assembling my portable supercomputer, I discovered that the cables I had ordered were too short. I had neglected to allow for the strain-reliefs at each end and the need to not stress the sockets these cables are plugged into. I should have used the longer cables I have to determine the length I needed before ordering all the cables for the project.
Bad Ideas Trying to launch a two-years dormant VM on a current version of VirtualBox on a 7 year old computer that is definitely showing its age. This was prompted by a change in policy by Code 42 Software, the owners of CrashPlan, a very good backup program and service. The new policy is to delete cloud repositories for computers that have not connected in over 6 months. This is only an issue as I have a couple of Windows VMs that I keep for the rare times I need a Windows environment.
tl;dr Hugo doesn’t do anything with a file that it hasn’t been told how to handle. I host the source for this blog in a Github repository. Github will place a notice suggesting a Readme if one doesn’t exist. In general, this is a good idea. It let’s the developer describe what the code hosted in the repository is intended to do or support. It can be used as initial documentation for a small project and a jumping-off point for a larger project.
I’ve always heard that the best way to really understand something is to explain it to someone else. Today, I learned a related truth: Trying to explain something to another is a good way to find out what you do not know. I’ve been dealing with data communications for pretty much my entire professional career. I understand how a signal travels along a wire, and have used this to find where that wire is broken.