Employing random hardware for Litecoin mining

Cryptocurrencies are a prominent trend at the moment, with Bitcoin (BTC) leading the way. In fact, BTC seems to already have passed the limits of hype and boomed also financially to the extent that mining of BTC is hardly anymore profitable unless you have a state of the art mining rig (and there is a chance the rig won't pay for itself as the mining difficulty rises). For the ones who want to try the ever-lucrative miracle of getting bucks out of thin air (or more precicely, out of CPU/GPU cycles), there are fortunately many alternatives left. Litecoin (LTC) is maybe currently the most prominent alternative for BTC (at least measured by market capitalisation) that can be mined (source: coinmarkercap.com). Ripples is ahead of LTC in market cap but it works differently to the likes of BTC.

That's it for the financial part of this post. I'll give whatever I will get mined to charity, and with the hardware I have there's no risk of getting rich in this business. Anyway, I got interested of the possibility to easily harness the processing power of unused hardware along the lines of plug it in and leave it there to crunch numbers. The same idea could be employed to anything that uses massively distributed processing.

I selected a live Linux distro on a USB stick as the OS for the experiment. Linux, since it doesn't require much resources, is easy to tweak and free to use, and I'm more familiar with it than Windows. Grml Live Linux was the one I chose to use, mostly because of the small footprint (good fit for old 512MB sticks).

There were two things in this project that I hadn't done before: customising a live distro (to add miner software) and re-producing a bootable ISO image. The first part ended up being pretty trivial, even though Grml uses squashed file system so I had to unsquash it first and squash it up again after modifications. Since I won't need to retain any run-time changes in the filesystem between reboots squashfs is just fine for the purpose.


Customising of the live image

Mount the original Grml ISO and copy it somewhere for modifications:

> sudo mount /var/tmp/grml32-full_2013.09.iso -o loop /media/cdimage
> cp /media/cdimage /var/tmp

Unsquash the root filesystem, modify it and put it back together:

> mkdir /var/tmp/grml32-custom
> cd /var/tmp/grml32-custom
> unsquashfs /var/tmp/cdimage/live/grml32-full/grml32-full.squashfs 

[copy stuff and adjust to run on the target setup]

> cd ..
> mksquashfs grml32-custom/squashfs-root/ \
  /var/tmp/grml32-custom_2013.09.squashfs -b 262144
> cp grml32-custom.squashfs /var/tmp/cdimage/live/grml32-full/

I ended up using the same block size for the squashfs as the original (thus "-b 262144"), but likely that doesn't matter much other than reduced overhead for large files since the default block size mksquashfs uses is pretty small.

Finally, to save space, I deleted the original .squashfs file from live/grml32-full/ and modified live/grml32-full/filesystem.module to point to the customised version.


Re-building the ISO

This took me a while to solve, since there were all kinds of instructions on the net how to produce a bootable ISO, but none worked. With genisoimage I got as far as being able to boot with the image file using QEmu, but after copying the image on the USB stick it wasn't working anymore. The issue seemed to be that the image didn't contain proper partition table (checking with cfdisk showed no partitions). Of course, one could just have the contents of the root partition in the image and then install boot loader manually after installing the image, but I preferred to produce a neat and simple image that does everything the original one does, too.

I finally ended up using xorriso as instructed somewhere:

> xorriso -as genisoimage -r -o grml32-custom_2013.09.iso \
  -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat \
  -no-emul-boot -boot-info-table -boot-load-size 4 \
  -V "GRML_custom" -iso-level 3 -partition_offset 16 \
  -isohybrid-mbr /usr/lib/syslinux/isohdpfx.bin /var/tmp/cdimage/

Finally, just I just cat'd the image on the USB drive.

This required me to install xorriso and syslinux and their dependencies from the Debian repository, but that was all extra that was needed.


The aftermath

I used cpuminer in this experiment because that is what I use on my boxes anyway (couldn't get cgminer to compile, and I doubt my low-end GPUs would provide much extra power anyway). I had built init.d script for minerd which makes it rather easy to construct a plug-in-and-mine solution.
The nice thing here was that Grml had all the required libraries already so I had just to copy over the executable, scripts and config files. I don't know how much it affects that I am now running an executable built for old AMD Athlon XP on a Intel Core i5, but unless there is good evidence that compiling for a newer target CPU would do any good, I don't bother. At least this way the executable should run on pretty much all hardware that is worth trying - the old Athlon XP here gets about 0.8 khash/sec which is pretty near at not worth trying...

Interestingly, running 4 miner threads on the Core i5 chip (which advertises 4 cores due to hyper-threading) gained about 14.1 khash/sec, but since that also meant having the laptop fan blow at top rpm constantly, I changed to running only 2 miner threads, still gaining about 9.7 khash/sec. This is a good example on the limitations of shared-something CPU architectures, but probaly also an example on how the turbo boost technology can compensate by reaping the headroom left in TDP due to only using part of the chip.

(edit: after measuring the actual power draw with both 4 and 2 mining threads it was obvious that the power vs. hashing efficiency is much better with 4 cores)