I was one of 10 to receive a free BPI-M2+ sample to test one of my projects on. Many months prior to even registering on the forums here, I was comparing the differences between the Raspberry Pi, Orange Pi, and Banana Pi. When it came down to it, Banana Pi seems to be ahead of the game as far as hardware specs are concerned. I was highly impressed and considered buying one for a community project I really wanted to host. After entering the BPI-M2+ sample contest, I was selected and began working on my project. I wanted to test stability and overall reliability prior to posting any sort of review. After having my project up and running for nearly 1 month, this is my review of the BPI-M2+ 
The BPI-M2+ shipped out in under a week. When I retrieved my package in the mail, I was very excited to set everything up. The board shipped in a tiny compact box, inside of an anti-static bag. The first task would be to find a reliable power cable, load an image onto the sdcard, and flash an image to the eMMC.
My luck wasn’t so good with the Verbatim 8GB Micro SDHC card. This was a UHS 3 Class 10 card that I picked up for under $5. I tried flashing 5 different images and could not get the thing to boot. Images included different flavors of Debian, Arch, Ubuntu, & Android. Not a single one would boot. I thought my BPI-M2+ was DOA since the HDMI wasn’t even detected when I would power it on. It boiled down to 1 thing. The BPI did not like my Verbatium sdcard. I found a small 2GB SanDisk in my phone, flashed a minimal Ubuntu image to it, put it in and the thing booted right up.
From there I was able to flash a Raspbian Lite image that I copied to my USB drive. The entire process took under 5 mins. Then I booted the BPI-M2+ via eMMC for the first time. Wow was I impressed! The entire thing booted in < 30 seconds. It was now time to work on getting my project live. My project has 2 main tasks, one being an ongoing developmental project titled QuakeSMS. QuakeSMS is a script that runs in the background and tails a specified logfile of any Quake game. When it sees a string in the log appear, it sends out an SMS and email to a distribution list of users, notifying them that a user has connected to the server. This is still a work in progress. I am currently working on getting this to sync to a master server, so the master server sends out a distribution from servers that send out logs.
The core of my project relied on arm7 binaries for uhexen2 (HeXen II: Hammer of Thyrion & HeXenWorld). Before signing up I had no idea this was part of Debian contrib. I had pre-compiled binaries ready to go. Pulling the latest packages from testing, I installed them and got the pak files for HeXen II into their corresponding directories. It was time to fire a server up. What I noticed immediately is that the Debian arm7 binaries seem to care more about the server flags than the binaries hosted on the sourceforge site (not to digress).
After writing a script to auto load my server flags, settings, and maps I put in a cron job so anytime there is server maintenance the game starts instantly at boot. I now had 7 dedicated servers running on 1 box, essentially every game mode. In the very beginning of this project (before my cron jobs were setup) I was running awesome as my window manager. I had cut down a huge slew of the services I didn’t need, things like bluetooth, and wifi. The server now booted in < 14 seconds…WOW highly impressive! While still running awesome (with no cron jobs to auto load the dedicated servers) I was running somewhere ~302MB of RAM and utilizing about 12% CPU. I wanted to reduce this further and go completely headless. Once the cron jobs were in place I no longer needed awesome at boot…this cut RAM usage down to 186MB and CPU utilization down to 6.7% running 7 dedicated servers.
Earlier this year, myself and a team of dedicated users set out on a journey to bring back multiplayer in HeXen II & HeXenWorld. In the very early months, I developed a simple php script on our site that would allow users to input their server IP which is then queried from our modified GS3D tool (Linux users can use XQF to pull the server list and it works perfect). This allowed users across the world to serve up games from their own home or dedicated box. We still lacked a 24/7 99.9% uptime solution. The BPI-M2+ was just that! It has renewed multiplayer in our community as we haven’t had a working multiplayer solution or the infrastructure to deliver it in nearly 15 years. So the game basically went dead. We now have a reliable server running on cutting edge technologies and users access it across the world almost daily! The BPI-M2+ has delivered with exceptional results!
In the coming days I will do a video review of the BPI-M2+ and demo of how the game works from a multiplayer infrastructure perspective.
For downloads, development, and project news you can visit our page at: http://hexenworld.org
Thanks BPI