First Problems

Posted on August 16, 2016 by

My next step was to clear out some cruft in the default install. There was plenty of RAM for the jobs, but not very much free space on the 8G intel flash. After deleting all the various office and other packages I had about 1.5G free, so I tried to move the little thing over to the server rack. But when I plugged it up over there, I couldn’t get in… hmm, brought it back to the monitor, all works great. It doesn’t work w/o something connected to the HDMI port. That’s not going to work for my application.

After some web searching, this is a known problem / omission. But Intel actually had a fix, just need some new firmware. That’s the usual horrible process, of downloading some files from some cumbersome-to-use web site, putting them on a FAT formatted USB drive, booting while holding down some keys ( already a problem for a device with a single USB port… ) then running through some menus and engaging the flash updater. It was a slow process as the firmware is checked multiple times, etc. but it worked. Now it could boot ‘headless’. There’s still one issue, if you boot it headless and there’s a problem, you can’t just throw a monitor on it, the HDMI is completely disabled,  you have to reboot with a monitor attached.  Kinda kooky, but not a show stopper.

Now it’s living in the ‘rack’, and I can connect remotely, time to delete some more stuff and try to get the provided ubuntu up to date. I removed all the X stuff and the boot splash, so if I do connect a monitor I just get a big console window — as it should be. This freed up a bit more disk space, about 1.8G free now, and a tiny bit more RAM. However after all the updates, there’s a new problem. poor response time over the net. Long delays between single character echoes when using ssh, and wildly varying ping times — from 5ms to 1500ms.

Now, of course, the built in wireless/BT controller is non-standard and there are limited driver options, but after some more web searching it looked like it was used in a few other devices and there were some options. Although it would be possible to continue forward using USB->ethernet adapters, that would be costly, add a lot of wiring complexity, and slow ( USB2 ). So I thought I’d try some other options first. I mostly use FreeBSD and MacOS, but when I’ve used Linux over the past few years I’ve used Arch. So I looked to see if there was an Arch for it — there was, but reading through it was based on a much newer ubuntu branch, and there were conflicting reports concerning the wifi driver. In fetching a bistro to test I came across lubuntu, which is a ‘small’ ubuntu. I build a thumb drive with that on it and proceeded to boot.

Another problem. Not booting. Starts to boot then USB hub led on the thumb drive drops and the boot hangs — hmm. This was a brand new A-Data 16G USB3 drive, for which I had paid the princely sum of $9.99 — for 3 of them. Well, okay, so I pushed it to a quality but older device and all went fine. The install went smoothly and the wifi was discovered and worked right out of the box. And as-is the Lubuntu distro was pretty small. After updates and before deleting any packages, 2.7G free… That saves some steps. I setup headless booting again and ssh and all is well. There’s still the occasionally slight slowness, and ping reports most times from 3-8ms, but there’s the odd 20-30ms.

This site: http://linuxiumcomau.blogspot.com.au/2016/08/running-latest-ubuntu-on-intel-compute.html has all the info and even links to distros. There’s an indication of occasional hangs, and an option to force cpu state 1 — i.e. disable some of the idle power saving stuff — that’s rumored to prevent that. If these enter production, they won’t be idle much anyway, so no big loss there. There are also rumors that using bluetooth causes slowness and stuttering on the wifi ( same chip handles both ), so I’ll either disable that in the BIOS or make sure nothing in the OS is trying to use it.

There’s also an option in the BIOS to enable maximum performance mode, I think this is in addition to the cpu-state stuff, as it limits power available on the one USB port. I will enable that since I’ll mostly not be using the USB port, and when I do it’ll either be with just a keyboard or with a powered hub anyway, so…

Next steps are:

  • Order some more and a big multi-port USB charger
  • Build a recipe for installing all the components dGrid needs
  • Figure out the best way to mass install Lubuntu
  • Port dGrid, and build an installable Linux package
  • Mounting / Packaging of a quantity of them
  • Private wifi setup for node
  • Custom node controller which can swap in Linux binaries for MacOS ones
  • Changes to the master controller to migrate last XXX Jobs to certain nodes
  • Tons of testing and verification
  • This and other documentation.

Off we go…

This entry was posted in dGridMicro

Sorry, the comment form is closed at this time.