Break-Even Performance/Cost Evaluation of Two Computers

So, my cheapie motherboard is on it's way and still waiting on my Pine64 to be shipped.  Hmmm...  I have been wondering how I can evaluate which platform will get me the best 'bang for the buck.'  Well, the main job of these machines is to use ImageMagick and maybe some other image utilities, to comb through hundreds (or thousands or millions) of photos and identify meteors.

So...  I start at total system cost.  A complete Pine64 should cost about $40 (inclusive of processing board, flash drive and power supply).  A complete, low-end AMD system using an AMD Dual-Core Ontario C-70* processor  (from NewEgg) should cost about $85 (inclusive of motherboard, processor, 4GB RAM, flash drive and power supply).

I want to evaluate which is a better value based on the amount of time required to process the same 100 images through the same processing steps.  It is really a pretty simple calculation; just required me to open some cranial doors to past algebra classes...  Those door hinges were rather creaky this morning. :-)

The calculation is simple and based on the ratio of  costs; in this case, 40/85.  Let's say the Pine64 requires 10 minutes to process 100 images.  For the AMD solution to be a better bang for the dollar, how many minutes should it take on the AMD platform to process the same 100 photographs?  simple...  10 * (40/85)  or 4.705 minutes.  Any longer and the Pine64 is a better deal.  Any less and the AMD solution is better.

And...  by inverting the ratio, we can solve how many minutes are required by the Pine64 to have a higher performance; 85/40.  Let's say the AMD requires 5 minutes to process 100 images, then 5 * (85/40) = 10.625 is the breaking evaluation point.  If the Pine64 takes less than 10.625 minutes, it is a better deal.

So...  Some algebra...
p1 - Price of system 1
t1 - Time to perform a process on system 1
p2 - Price of  system 2
t2 - Time to perform a process on system 2

t2 = t1*(p1/p2)  - use if t1 is known and looking for t2
and
t1 = t2*(p2/p1)  - use if t2 is known and looking for t1

If the real world results are less than or equal to the above results of t2 or t1, then that system is better in terms of performance/cost.

Now, back to something a bit more simple - website migrations, SQL optimizations and thredifying single thread processes...  oh boy oh boy.

* - Processor and Board Disclaimer - Yes, I know the AMD C-70 is an older, less powerful processor.  That, however, means that available motherboards are quite inexpensive.  Plus, the power consumption of the C-70 is really very low - big plus.

Oracle VM VirtualBox - Just a Misleading Error Message

Three weeks of fighting a "cold from hell" gave me time to think about my little project to automate a search for meteor photos.  Sure, I have a PINE64 on order.  Sure, it may be delivered later in March.  Sure, there may be a flavor of Linux available for it sometime soon.  Sure, I may be able to build ImageMagick and other tools I need for the Pine64.  Sure, the performance may be acceptable for my goal.  Crap, no planned PXE/net-boot planned.

What if...  Let's see...  a complete Pine64 compute node with 1GB Ram and the OS on an 8GB flash drive will cost roughly $35 accepting a lot of "maybe" assumptions.  Let's remove the assumptions and calculate the cost of a good old AMD or Intel processing node.  Looks like a 64 bit AMD based system with 4GB RAM, with PXE boot will run about $85.

So...  I decide to emulate a 32 bit Debian text-only install on an Orable VM Virtual box using 4GB Ram to sort-of emulate the AMD solution.  Which gives me an idea for a new word...

umulate - An emulation that is not exact; allowing certain differences for the sake of brevity or simplicity.  "I am going to umulate this Debian install; the real machine will not have a hard drive, but will boot from a flash drive."  But...  I digress...

BUT SMACK...  An error pops up from Oracle Virtualbox when I try starting the virtual machine...

Failed to open a session for the virtual machine DebianPNode.

Under "Details" it read...

VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_MSR_ALL_VMX_DISABLED)

Well, after some research and comparing this virtual machine with the operational virtual version of Debian, I arrived at a repair that seemingly has nothing to do with the error.  I changed the Base Memory for this Virtual machine to 3072 GB and SHAZAM.  No more error.  Keep in mind, my machine has 8 GB and runs a pretty lean install of 64 bit Windows 7.  Why this misleading message popped up, I have no idea...  but reducing the Virtual machine's Base RAM fixed the problem.

Teaching an Old Dog New Tricks.

Regardless the age of an old programming dog, new tricks are pretty important to learn.

My initial success with night sky photography with my Canon EOS Rebel T3 tumbled in my mind over the last few days.  Recorded remnants of a thought from a few years ago popped up when searching an old personal hard drive...  An automated search for meteor photos.

Well, I was nearly there.  After spending a few nights with ImageMagick and some meteor photos, I built a basic recipe to find meteor strikes in night sky photos.

Hey, I thought...  I have a PINE64 on order.  Wouldn't that be cool to make one of these tiny ARM based computers comb through photos for meteors?  Ohhh...  With a little thought this could be easily scalable.  What about controlling my camera with one of these PINE64 computers?  Maybe a loosely coupled cluster of these $15 computers to search these photos in different ways?

I needed a control language for this; something interpreted and not terribly complex.  It only needs to be able to run shell commands, copy files and talk to MySQL.  Lua had my vote until I tried MySQL.  After two hours of trying to make it work on my Windows 7 computer, the necessity for a different language became apparent.  Sorry Lua.

A buddy of mine at work likes Python.  My daughter learned a little Python at college last year.  Python is a language specifically being ported to the Pine64.  The memory footprint of Python is larger than that of Lua but should work fine in the constrained environment of the Pine64.  MySQL Connector was easy to install and setup.  After a running a few little trial scripts, I was convinced Python would be my control language for this little project.

So, over the last week or so, this old dog has learned a few new tricks; and he is enjoying it!