Author: mininodes

Posted on by — 5 Comments

Where to Buy an Arm Server

Being Arm enthusiasts and deeply embedded in the Arm Server ecosystem, one of the questions we get asked often is,

“Where can I buy an Arm Server?”

In the past, it was difficult to actually find Arm Server hardware available to individual end-users. Not long ago, the only way to gain access to Arm Servers was to have NDA’s with major OEM’s or having the right connections to get engineering-sample hardware. However, over the course of the past 2 to 3 years, more providers have entered the market and hardware is now readily available to end users and customers. Here are some of the easiest ways to buy an Arm Server, although this list is not exhaustive. These servers all have great performance and are well supported thanks to standards compliance and UEFI.

First up is the Marvell ThunderX, and newer ThunderX2. These chips are sold in servers from several vendors, which come in various shapes and sizes. Some of the examples we’ve found include the Avantek R-series in both 1U and 2U sizes, and the Gigabyte Arm offering that closely match Avantek’s specs. There are High Density designs, single processor and dual processor options, and 10 GBE as well as SFP options available.  ThunderX2’s have been more popular in HPC environments, but even a first-generation ThunderX is a great choice, and still a very powerful machine.  They can be purchased with up to 48-cores, or in dual-processor configurations then containing up to 96 cores.

Another option is the Ampere eMag Arm Server from a company that formed a few  years ago, Ampere Computing.  They ship a turnkey Arm Server that is sold by Lenovo, the HR330A or the HR350A.  Their first-generation platform has 32 Arm cores running at 3.0ghz, 42 lanes of PCIe bandwidth, and 1 TB of memory capacity, and their second-generation product, the Ampere Altra, has up to 80 Arm Neoverse N1 cores.  Current models are available for purchase from their website, or through Lenovo.

Finally, although it is marketed as a workstation, the Solid Run Honeycomb LX2 motherboard can quite easily be repurposed as a proper server.  With 16x A72 cores, support for 64gb of RAM, up to 40gb Ethernet, and PCIe expansion, it can definitely handle medium sized workloads.  It is standards-compliant, making it easy to install your OS of choice, and affordable, thus its a great option for getting started on Arm.

And of course, if buying physical servers and hosting them yourself, or placing them in a datacenter, is not feasible or cost effective in your situation, then our hosted Arm servers are a great option as well!  Our miniNodes Arm servers are certainly more modest in comparison to those mentioned above, but, they are a great way to get started with Arm development, testing existing code for compatibility, or lighter workloads that don’t require quite so much compute capability.

Be sure to check back often for all things Arm Server related!

Posted on by — 4 Comments

How-To: Install Minecraft Server on the Raspberry Pi Server or Ubuntu 18.04 Arm Server (2020 Edition)

Install Minecraft Server on the Raspberry Pi (2020 Edition)

Minecraft is one of the most popular games played online, and installing your own Minecraft Server on a Raspberry Pi or other Arm powered device is easy! These instructions will allow you to install Minecraft Server on our Raspberry Pi, Raspberry Pi 3, or on our Ubuntu 18.04 Arm Server.  They should also work locally on your own Raspberry Pi or other Arm powered single board computer!

To install Minecraft Server on your Raspberry Pi, just follow this quick tutorial to get you up and running!

Installing Java

Due to changes in the Oracle licensing, it is no longer possible to download JDK directly from their site without accepting a license agreement, as was possible in the past.  Thus, it is no longer possible to just use ‘wget’ from a terminal to download JDK.  Instead, you will have to use a web browser, navigate to https://www.oracle.com/java/technologies/javase-jdk8-downloads.html, and select the “jdk-8u241-linux-arm32-vfp-hflt.tar.gz” file.  This will need to be accomplished in one of two ways, depending on whether you are using SSH to connect to your server, or, if you are using a local Raspberry Pi with a desktop.  First, if you are using a local Raspberry Pi with a keyboard, monitor, mouse, and desktop installed, you can simply open up a web browser and visit https://www.oracle.com/java/technologies/javase-jdk8-downloads.html, and select the “jdk-8u241-linux-arm32-vfp-hflt.tar.gz” file.  Take note of where it downloads, we will need that in a moment.

If you are connected via SSH, you will need to use a terminal (text only) web browser such as Lynx.  This won’t be pretty, but, it should be enough to prompt for the download of the JDK file.  First connect to your node via SSH using the IP address, username, and password.  Then, install lynx and navigate to the Oracle website in text-only mode:

sudo apt-get install -y lynx && lynx https://www.oracle.com/java/technologies/javase-jdk8-downloads.html

Look for the text on the page where the name of the file is listed, jdk-8u241-linux-arm32-vfp-hflt.tar.gz, and press Enter to start the download.  If you are on a desktop version of the Raspberry Pi, now is the time to switch to the Terminal application, and change to the directory where your file got downloaded to (most likely Downloads … cd Downloads).  If you connected via SSH, then you are already in a terminal, and can proceed.

We need to extract Java, using this command:

sudo tar zxvf jdk-8u241-linux-arm32-vfp-hflt.tar.gz -C /opt/

If the download and extract were successful, we will test to make sure Java is working by:

sudo /opt/jdk1.8.0/bin/java -version

We should see this, confirming Java is now ready (your version may vary a bit):

java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
Java HotSpot(TM) Client VM (build 25.0-b53, mixed mode)

Finally, let’s remove the downloaded gzip to save a bit of disk space:

sudo rm jdk-8u241-linux-arm32-vfp-hflt.tar.gz

Installing Minecraft Server

Now, it is time to download Minecraft Server!

Still in the terminal, get Minecraft from this URL:

wget https://launcher.mojang.com/v1/objects/bb2b6b1aefcd70dfd1892149ac3a215f6c636b07/server.jar

Once it has finished downloading, we can launch it by running:

sudo /opt/jdk1.8.0/bin/java -Xmx1024M -Xms1024M -jar minecraft_server.1.15.2.jar

The original Raspberry Pi Model B only has 512mb of RAM, so it will not actually allocate 1024…but it will take approximately 400mb or so that is available to it.  The Raspberry Pi 3 and our Ubuntu 18.04 LTS Arm Server both have 1gb of RAM, which definitely helps increase performance of the Minecraft Server.  Of course, the Operating System does take up some of the available memory, but Minecraft Server will probably reserve about 750mb to 800mb of memory to run, which will be plenty.  On a Raspberry Pi 4 you can purchase up to 4gb RAM models, so if you have one of those, feel free to experiment with increasing the value of the memory, (1024) in the above command line (perhaps 2048)

At this point, Minecraft Server will go through it’s startup routine, and you will be able to join the newly created world by pointing your game to the IP Address of your node (you can also modify game variables by editing the server.properties file, located in your ~home directory.)

Have fun!

Posted on by — Leave a comment

Running AI Workloads on Arm Servers

Arm’s Role in Processing AI Workloads

The past several years have seen enormous gains in Artificial Intelligence, Machine Learning, Deep Learning, Autonomous Decision Making, and more.  The availability of powerful GPUs and FPGAs both on-premise and in the cloud for several years now have certainly helped, but more and more of this AI processing is actually being done at the Edge, in small devices.  The popularity of Amazon Alexa, Google Home, and AI-enabled features in smartphones such as Apple’s Siri has skyrocketed over the past few years.  The various frameworks and models such as Tensorflow, PyTorch, Caffe, and others have matured, and newer, lightweight versions have come along such as TinyML, TensorflowLite, and other libraries designed to allow machine learning in the smallest devices possible.  Local processing of audio and detecting specific sounds via wavelength pattern matching, object recognition in a camera’s frame, motions and gestures being monitored and observed, and vehicle safety systems that detect and respond immediately to changing conditions with no human intervention are some of the most common applications.

The work that it takes to develop these AI models is very specialized, but ultimately algorithms are created, a large sample of training data is fed in to the system, and a model is developed that has a confidence factor and accuracy value.  Once the model is deployed, real-time stream processing occurs, and actions can be taken based upon the results of data flowing through the application.  In the case of a computer vision application for example, identifying certain objects  can result in alerts (hospital staff notified), corrective actions (apply the brakes immediately), or data stored for later use.
As mentioned, more and more AI/ML is actually being processed at the Edge, on small form factor devices.  And, small form factor devices tend to be powered by Arm SoCs, as opposed to the more power hungry x86 designs commonplace in laptops and desktops.  Home devices like Alexa, Google Home, and nearly all smartphones are based on Arm SoCs.  Thus, AI models need to be created, tested, and compatibility verified for Arm powered devices.  Even if an algorithm is developed and trained on a big GPU or FPGA, the resulting model should still be tested on Arm SoC’s to ensure proper functionality.  In order to help speed the testing process, miniNodes now offers hosted Arm microservers with dedicated AI accelerators, that can assist with offloading AI tasks from the CPU and offer excellent machine learning performance.  Testing of self-driving vehicle object detection, navigation and guidance, and actions / behavior models, image classification and object recognition from cameras and video streams, convolutional neural networks, and matrix multiplication workloads, robotics, weather simulation, and many types of deep learning activities can be quickly and easily processed.

Arm Lowers the Cost of AI Processing

AI training and inference in the cloud running on Arm microservers at miniNodes also offers a distinct cost advantage over Amazon AWS, Microsoft Azure, or Google GCE.   Those services can very quickly cost thousands of tens of thousands of dollars per month, but many AI workloads can get by just fine with more modest hardware when paired with a dedicated AI accelerator like a Google Coral TPU, Intel Movidius NPU, or Gyrfalcon Matrix Processing Engine.  AWS, Azure, and GCE provide great AI performance, sure, but you also pay heavily for the processor, memory, storage, and other components of the overall system.  If you are ready to make use of those immense resources, wonderful.  But if you are just starting out, are just learning AI/ML, are only beginning to test your AI modeling on Arm, or just have a lightweight use case, then going with a smaller underlying platform while retaining the dedicated AI processing capability can make more sense.

miniNodes is still in the process of building out the full product lineup, but in the meantime Gyrfalcon 2801 and 2803 nodes are online and ready, with up to 16.8 TOPs of processing for ResNet, MobileNet, or VGG models.  They are an easy, cost effective way to get started with AI processing on Arm!

Check them out here:  https://www.mininodes.com/product/raspberrypi-4-ai-server/

Posted on by — Leave a comment

Recap: Building an Arm-Powered IoT, Edge, and Cloud Infrastructure

Intro

At Arm’s annual TechCon event in San Jose, Arm CEO Simon Segars presented a vision of the future where a trillion connected devices interact seamlessly with each other and pass data between the Cloud, the Edge, and the Internet of Things, at a scale unimaginable even just a few years ago. Self driving cars will generate massive amounts of sensor information and data, 5G wireless will enable increased connection speeds and reduced latency, and artificial intelligence will provide scientific breakthroughs in materials, technologies, medicines, and energy. This vision of the future state of the connected world is something we have heard about for several years now, with countless written articles, interviews, social media posts, conference talks, and various other forms of media addressing the topic.

However, when seeking out real-world examples of this architecture in practice to help learn and understand how the bits and pieces work together, we came up empty. There were no purpose-built sample projects, pre-written code examples, or other working prototypes of these principles available. Surely there are some internal, private teams building out this type of infrastructure for specific use-cases and organizational needs, but there were no public / open projects to learn from.

Thus, it was time to take action, and build a prototype infrastructure ourselves! With the help of the Arm Innovator Program, we set out on a journey to develop a proof-of-concept that encapsulates as many of these concepts as possible, leveraging currently available technologies and showcasing Arm’s diverse portfolio of products and ecosystems. With help from the Works on Arm program via Packet.com, we began brainstorming.  Our goal was to deploy IoT endpoints to a handful of locations around the world, and capture environmental data via sensors on those devices. From there, we wanted to feed that data to a local Edge Server, which would be responsible for translating the data to a usable format and sending it further upstream, to a Cloud Server functioning as a data warehouse and visualization platform.

In this article we’ll take an in-depth look at the project, and detail the key technologies to give a better idea of what this kind of system entails. I’ll also provide a summary of our lessons learned, which hopefully help you to build and iterate faster, and avoid some potential pitfalls along the way.

Design

When thinking about the design of this project, we wanted to keep things simple, as the purpose of this exercise it to demonstrate capability and build a proof-of-concept, but not an actual product shipped to real, paying customers.  Thus, we made hardware and software selections based on cost and availability, as opposed to “most appropriate” for the intended use. We also knew we would have relatively small data-sets, and reliable power and internet connectivity for all of our devices.  Your real-world IoT deployments may not have these luxuries, so, your hardware and software selections may not be as straightforward as ours were.  Many IoT projects have to be tolerant of lost network connectivity, unreliable power delivery, or harsh environmental conditions.  But we were fortunate to have consistent power and internet.  Let’s go through our inventory of Arm-powered hardware and software, keeping in mind the rather ideal conditions we’ve got:

1. IoT Endpoints

Hardware

  • Raspberry Pi 3B+
  • Sparkfun Qwiic HAT
  • Sparkfun Lightning Detector
  • Sparkfun Environmental Combo Sensor
  • Sparkfun GPS Sensor

Software

  • Arm Mbed Linux OS
  • Arm Pelion Device Management

 

2. Edge Nodes

Hardware

  • Linaro / 96Boards HiKey, and HiKey 960

Software

  • Linaro Debian Linux

 

3. Cloud Server

Hardware

  • Ampere eMAG, hosted by Packet.com

Software

  • Debian Linux
  • InfluxDB
  • Grafana

 

As you can see, we have made some selections that fit our small project well, but as mentioned may not be suitable for all IoT use cases depending on your project’s environmental conditions.  However, let’s start detailing the items, beginning with the IoT Endpoint.  We’re using a Raspberry Pi 3B, a Sparkfun Qwiic HAT, and Sparkfun sensors to capture Temperature, Humidity, Barometric Pressure, CO2, and tVOC (volatile organic compounds).  We have lightning detection capability (currently not being used, but, available) as well, and GPS so that we can determine precisely where the Endpoint is located.  As for software, because these devices are out in the wild, scattered literally across the globe, we needed a framework to allow remote monitoring, updating, and application deployment.  Arm Mbed Linux OS is a lightweight, secure, container-based operating system that meets these requirements.  It is currently still in Technical Preview, but is far enough along in development that it meets our project needs and is working great.  A total of 10 Raspberry Pi Endpoints were built and sent around the globe, with several across the United States, as well as Cambridge, Budapest, Delhi, Southern India, and one spare unit left over for local testing.

Turning to our Edge Nodes, these are the simplest component in our project’s infrastructure. These are 96Boards devices, chosen for their support and ease-of-use.  Linaro and the 96Boards team do an excellent job of building ready-made Debian images with updated kernels, applications, and drivers for their hardware, making for a great out-of-the-box experience. Two of these devices are currently provisioned, one in India and one in the United States, each serving their geographic region. The devices aggregate the IoT Endpoint data stream, convert it to the format needed by the Cloud Server, and publish the data to the Cloud.

Finally, the Arm-powered Cloud Server is an Ampere eMAG server, hosted by Packet.com. It is an enterprise-grade machine, and functions as the data warehouse for all of the IoT data, as well as a visual platform for charting and viewing the data in a time-series fashion thanks to InfluxDB and Grafana. Packet.com has datacenters around the world, and their native tooling and user interface make deploying Arm Servers quick and easy.

Now that the system architecture has been described, let’s take a look at the application architecture, and start to dissect how data flows from the IoT Endpoints, to the Edge, to the Cloud. As mentioned, Mbed Linux OS is a container-based OS, which is to say that it is a minimal underlying operating system based on Yocto, providing a small, lightweight, secure foundation to which the Open Container Initiative (OCI) “RunC” container engine is added.  RunC can launch OCI compliant containers built locally on your laptop, then pushed to the Endpoint via the Mbed Linux tooling, no matter where the device is located.  In our particular case, we chose a small Alpine Linux container, added Python, added the Sparkfun libraries for the sensors, and created a small startup script to begin reading data from the sensors when the container starts.  The container also has an MQTT broker in it, which is responsible for taking that sensor data, turning it into a small JSON snippet, and publishing it to a specific known location (the Edge Server).

The Edge Servers are a more traditional Debian operating system, with Python installed as well.  There is a Python script running as a daemon that captures and parses the incoming MQTT from IoT Endpoints, converts it to an InfluxDB formatted query, and publishes it to the specified Influx database, which is running on the Ampere eMAG Cloud Server.

Finally, the Cloud Server is an enterprise-grade Ampere eMAG Arm Server.  It is graciously hosted by the Works on Arm project at Packet.com, in their New Jersey datacenter. This server is also running Debian, and has InfluxDB and Grafana installed for storage and visualization of the data being sent to it from the Edge Nodes.  Thus, our IoT, Edge, and Server are all Arm-powered!

Construction Challenges

Building a container to hold our application did prove more challenging then anticipated, as a result of some needed functionality not provided by the ready-made Mbed Linux downloads. Normally, this could be easily solved by adding the desired packages to the Yocto build scripts and rebuilding from source…however, there is one additional and very unique quirk to this project: We have decided to exclusively use Arm-powered Windows on Snapdragon laptops to build the project!  These laptops are highly efficient, with all-day battery life and far better performance than previous generations offered.  One limitation however, is they are currently unable to run Docker, which we would need to re-build Mbed Linux from source.  Thus, instead of adding the necessary packages to Yocto and recompiling, we instead had to manually port Device Tree functionality, gain access to the GPIO pins on the Pi, enable the I2C bus and tooling, and finally expose that functionality from the host OS to the container, all by way of manually lifting from Raspbian.  Obviously, we placed this limitation upon ourselves, but it does demonstrate that there are still a few shortcomings in the developer experience on Arm.

A second valuable lesson learned is with the native Mbed tooling for initially deploying devices.  Provisioning and updating devices with Pelion Device Management is a straightforward process, except for one small but critical hiccup we experienced.  It is worth noting here again that Mbed Linux OS is in a Technical Preview status, and the feedback we were able to give to the Mbed team as a result of this process has been incorporated and will make the final product even better!  However, when following the documentation to provision devices for the first time, a Developer Certificate is issued. That certificate is only valid for 90 days, and after that time you can no longer push containers to a device in the field. That Certificate can certainly be updated via the re-provisioning process, but, you must be on the same network as the device in order to perform that action. Our devices are already out in the field, so that is not possible at this point.  Thus, we have a fleet of devices that cannot receive their intended application.  On the plus side, this exercise proved it’s worth by highlighting this point of failure, and resulted in the valuable documentation update so that your project can be a success!

Conclusion

In the end, we were able to successfully provision just a few devices that we still had local access to, and prove that the theory was sound and demonstrate a functional prototype at Arm TechCon!

Using a pair of freshly provisioned Raspberry Pi’s, the containerized application was pushed Over The Air to them, via the Mbed CLI.  Pelion showed the devices as Online, and the device and application logs in the Dashboard reported the container was started successfully.  Sure enough, on the Edge Node, data began streaming in, and the MQTT Broker began taking those transmissions, translating them to Influx, and sending them upstream to the Cloud Server.  Logged into Grafana running on the Cloud Server, that data could then be inspected and visualized.

Thus, while it wasn’t quite as geographically diverse as hoped, we did actually accomplish what we set out to do, which was build an end-to-end IoT, Edge, and Cloud infrastructure running entirely on Arm!  The data that is flowing is certainly just a minimal example, but as a proof-of-concept we can truthfully say that the design is valid and the system works!  Now, we’re excited to see what you can build to bring Simon Segar’s vision of the connected future to life!

Posted on by — 1 Comment

Raspberry Pi 4 AI Server Now Available

As pioneers in the Arm micro server ecosystem, miniNodes has been an innovator and leading expert in the use of small devices to fulfill compute capacity at the Edge, watched as IoT has matured and impacted all industries, and is now witnessing AI and Machine Learning depart the Cloud and instead be performed on-device or at the Edge of the network. More and more phones, home assistant devices (such as Echo), and even laptops are including custom AI hardware accelerator chips designed to handle voice recognition, gesture and motion control, object detection, analyze video and camera feeds, and perform many other deep learning tasks.

The AI models and algorithms that make this happen have to be trained and tested on specialized hardware accelerators as well, and historically that has been very expensive to perform in the cloud. miniNodes is taking a different approach however, and pairing custom hardware AI Accelerators with cost effective Raspberry Pi 4 servers, to lower the cost of testing and training these models while still maintaining high levels of performance. Deep learning, neural network, and matrix multiplication activities can be offloaded to the AI hardware, rapidly accelerating the model training.

The first product to launch in the new miniNodes AI Server lineup is a Raspberry Pi 4 server combined with a Gyrfalcon 2801 NPU, for a maximum of 5.6 TOP/s of dedicated AI processing power. In the future, we will expand the lineup to include Google Coral and Intel Movidius hardware as well.

The Raspberry Pi has always been one of the most popular hosted Arm Servers at miniNodes, even as far back as the original Raspberry Pi (1) Model B, some of which are still running! Over the years, we upgraded to Raspberry Pi 2’s, 3’s, and the 3+. So, it was only a matter of time until we deployed new, faster Raspberry Pi 4 servers.

However, with the launch of the Pi 4 and its increased capabilities, we decided it was time to upgrade our infrastructure, management, and backend systems to match. That work is actually still ongoing, but in order to start testing the ability to run AI workloads, we have made a few units available for early adopters to begin testing their ML models. If you are looking for a cost effective way to get started with AI processing or are interested in testing AI/ML on Arm cores, this is a great way to get started. Check out the new miniNodes AI Arm Server here: https://www.mininodes.com/product/raspberrypi-4-ai-server/

And if you have any questions, just drop us a note at info@mininodes.com!

Posted on by — Leave a comment

Arm Server Update, Winter 2020 Edition

In the months since our last update, as usual, much has changed in the Arm Server ecosystem!  When assessing the industry and product performance in such an emerging field, things move fast!  Here are few observations and notes on the second half of 2019, and a look ahead to what to is forthcoming in 2020 for Arm Servers.

First, Marvell has continued to focus on the HPC market, and has promoted their ThunderX2 processor in talks, marketing materials, and social media posts focused on their National Laboratory projects and installations.  There is also some preliminary talk about their next generation product, the ThunderX3, though details are limited at the time of this writing.  In a sign of confidence, Arm directly invested a significant sum of money in the Marvell Arm Server processor as well.

Meanwhile, Ampere has had continued success with their eMag processor, including server sales through Lenovo, and a Workstation version of the platform now available as well.  Similar to Marvell, Ampere has begun to discuss their next generation processor as well, stating that it will have 80 cores, and will be based on the Arm Neoverse N1 reference architecture.  Again similar to Marvell, Arm has also invested directly in Ampere to keep momentum and product development strong, and more recently Oracle has invested as well.

Amazon has been competing strongly in the Arm Server market for the past year with their Graviton platform, which powers the AWS A1 Instance Type.  At the re:Invent conference, Amazon announced the Graviton2 processor, which will be available soon, and increases the core count to 64 and “deliver 7x performance, 4x the number of compute cores, 2x larger caches, and 5x faster memory compared to the first-generation Graviton processors” according to Amazon.

The last item to make note of is the SolidRun Honeycomb platform, which is technically marketed as a Developer Workstation, but could quite easily be adapted to a small server.  It offers a 16-core NXP Layerscape SoC, 4x 10gb Ethernet, SATA, PCIe, and a standard mini-ITX footprint.

As usual, if you have anything to add to the conversation, simply add your comments below, and we will continue to offer analysis and insight to all things Arm Servers!

Posted on by — 1 Comment

Hosted Raspberry Pi 4 Servers, Coming Soon

Can a Raspberry Pi 4 function as a server?

Since it’s launch in June, many people have been wondering whether a Raspberry Pi 4 can take on the role of a small server. With 2gb or 4gb of RAM now available on the boards, and a significantly faster Arm processor than the previous model, a Raspberry Pi 4 Server is absolutely possible!

Longtime followers will know that miniNodes has been hosting Arm Server single board computers for years, and may already realize that our current Raspberry Pi Servers are typically sold out. Demand for them has always exceeded our capacity (sorry about that!), and customers have realized that they function great as lightweight servers for certain use-cases. Testing code and applications on Arm processors for compatibility, running simple services that don’t need a lot of CPU / compute power, early IoT product development work, Edge node and gateway workload testing, and bare-metal (non-shared) access are some of the reasons users have been drawn to our hosted Raspberry Pi’s. However, the capability of the nodes is certainly modest with their 1gb of RAM and Cortex A53 cores.

Enter the Raspberry Pi 4 Server

The Raspberry Pi Foundation caught the world by surprise when it released the new Raspberry Pi 4 board a few months ago. As mentioned, it came with increased RAM, a faster processor, gigabit networking, and USB 3.0 ports. These upgrades directly addressed the performance and connectivity shortcomings of the previous generation, though “shortcomings” is probably unfair when talking about a computer the size of a credit card and costing only $35. However, with these new components, the Raspberry Pi 4 is a very capable machine, and more specifically with a quad-core Cortex-A72, 4gb of RAM, and USB3 attached storage it is certainly able to fulfill the role of a small server. Content and data caching, IoT data collection and aggregation, extreme-edge compute environments, small office branches, archival storage, email relaying, (small) in-memory NoSQL datasets, and many other purpose-fit workloads are entirely possible!

Raspberry-Pi-4-Server

As also mentioned, miniNodes has been involved in the Arm Server ecosystem for many years, and we have a lot of experience with the challenges of hosting single board computers. The biggest issue for most long-term Raspberry Pi users, and other similar SBC’s without onboard storage, is that SD Cards wear out and fail. SD Cards were never designed to have constant and continual reading and writing, such as occurs when a full operating system is installed and running on them. SD Card failure leads to the Pi crashing, with potential for data corruption and data loss. Another major hurdle when deploying Raspberry Pi’s in a cloud hosting environment is the lack of native management, remote console access, or other typical hardware control mechanisms found on traditional servers. In fact, even placing single board computers in a datacenter is a challenge, with voltage, physical dimensions, port placement, and cabling very different from a standard 1U or 2U server chassis.

But, with some creative engineering and subject matter expertise, miniNodes is going to address these challenges and build an infrastructure to allow the Raspberry Pi 4 and other single board computers to function in a cloud server capacity that is similar to the user experience developers are already familiar with.

(Small) Arm Cloud Servers

It will take a few months, and some trial and error along the way, but our current plan is to tackle each previously identified challenge and come up with a solution that is both scalable and customer-friendly. First and foremost, we need to move storage off of the SD Card, and onto a more robust medium. Thus, a new NAS system (also running on Arm!) is being developed, where each node’s OS will live, allowing higher performance, greater reliability, and data replication. Next, the ability to remotely power cycle nodes is being built, by a power distribution and relay that can change states upon user command. Cabling, cooling, and rack mounting are also under active development, with power, networking, and the physical layout of the boards in a 2U server chassis being optimized.

A lot has been written about the heat produced by the Pi 4, and placing lots of them in a server chassis is not going to help, so we are doing careful analysis of the thermal properties of the boards, and experimenting with heatsinks and fans, as well as the placement, direction, and airflow across the boards in the chassis. Internal temperature monitoring (and alerting) is also being developed for the chassis, to ensure intervention can occur if needed.

Here are some of our first experiments with cooling solutions:

[columns] [span4]

Raspberry-Pi-4-Server-1

[/span4][span4]

Raspberry-Pi-4-Server-2

[/span4][span4]

Raspberry-Pi-4-Server-3

[/span4][/columns]

Finally, a complete re-architecting of the miniNodes website and management portal is needed to interface with the new components, so a website rebuild and a new user interface will be rolled out as well.

These exciting changes will result in a better customer experience, improved products and services, and higher performing nodes. We’ll keep this blog updated with the latest information and developments (and lessons learned) as we continue to make progress on the project, but early estimates are that we will be ready for launch sometime in Q1 2020. As much as we’d like to offer our Raspberry Pi 4 Servers sooner, we want to make sure we do it right, and are able to give customers an improved service to go along with the improved boards.

Stay tuned, and, if there are other Arm devices you’d like to see included, just let us know. You can find us tweeting here https://twitter.com/mininodes, or, just shoot an email to info at mininodes.com.

Posted on by — Leave a comment

Arm Server Update, Summer 2019

It has been a while since our last Arm Server update, and as usual there has been a lot of changes, forward progress, and new developments in the ecosystem!

The enterprise Arm Server hardware is now mostly consolidated around the Cavium ThunderX2 and Ampere eMag products, available from Gigabyte, Avantek and Phoenics Electronics. Each can be purchased in 1U, 2U, and 4U configurations ready for the datacenter, and high performance developer workstations based on the same hardware are available, as well. Both of these solutions can be customized with additional RAM, storage, and networking, to best fit the intended workload.

Another option that exists, but is difficult to obtain in the United States, is the Huawei 1620, also known as the Kunpeng 920. These servers are also enterprise grade servers ready to be installed in a datacenter environment, typically in a 2U chassis with configurable memory and storage options. However, availability outside of Asia is limited, and new regulations may make importing them difficult.

While the Cavium, Ampere, and (potentially) Huawei servers are available as bare-metal options shipped directly to you for installation in your own datacenter, Amazon has also made significant progress over the past few months and is rapidly becoming the most popular Arm Server provider. They use their own Arm Server CPU called the Gravitron, that they use in their own proprietary AWS A1 ECS instances. This is quickly becoming the best way to deploy Arm Servers, as the entire system is in the Cloud and no hardware has to be purchased. They come in various sizes and price ranges, and experienced developers organizations who are familiar with the AWS system can simply pay by the hour for temporary workloads. For users who are less familiar with the ECS dashboard, less comfortable with the fluctuations in billing model, or prefer a fixed rate, we at miniNodes offer pre-configured Arm VPS servers in a range of sizes and prices, hosted atop the AWS platform.

Finally, the Edge of the network continues to be where a lot of innovation is occurring, and Arm Servers are a perfect fit for deplopyment as Edge Servers, due to their low power consumption, cost-effectiveness, and wide range of size and formats. The MacchiattoBin has been demonstrated running workloads in the base of windmills, the new SolidRun Clearfog ITX is promising to be a flexible solution, and the new Odroid N2 is an intersting device that has “enough” performance to satisfy a wide range of workloads that don’t need to always rely on the Cloud, and can instead deliver services and data to end-users (or other devices) faster by being located in closer proximity to where compute is needed.

As always, check back regularly for updates and Arm Server news, or follow us on Twitter where we share Arm related news on a daily basis!

Posted on by — Leave a comment

Arm Servers Need an Arm Desktop Unit of Computing

Finally.

We as an industry are finally having an open and honest discussion with ourselves, about why Arm Servers have not been as successful as we had all hoped, and why that is. Not excuses, just an analysis of facts and the consequences they have had.

To set the stage, let’s rewind 4 years. Arm had very high expectations for the Arm Server ecosystem, and made public statements on a regular basis that they intended to capture 20% of the Server market by 2020. We are now 9 months away from that date, and Arm Servers are closer to a 1% novelty still being explored and tested for workload compatibility by users.

In early 2015, the number was 20%, but by January of 2016 the number actually grew to 25%! Here is the opening statement from an article on the Next Platform at the time:

“So 2016 is the year, or at least it is supposed to be. The year when 64-bit ARM chips finally make their way into servers and perhaps start getting wheeled through the loading bays of actual datacenters to start running real workloads alongside the Xeon processors that by and large dominate in the glass house.”

And here are the 2015 claims:

That sentiment and the high hopes continued through the next several years, with Arm Servers always ‘just around the corner’, ‘ready to make a breakthrough’, or ‘poised to take marketshare away from Intel’. AMD entered and left the ARM Server SoC business. Qualcomm entered and left the Arm Server SoC business. Applied Micro was acquired and their Server SoC was abandoned, but fortunately came back via an acquisition of their IP. Either way, time and knowledge were lost.

That brings us to the present day.

Last week, Arm further revealed the E1 and N1 Neoverse processors based on the Ares architecture, which were previously announced last fall at ArmTechCon 2018. Performance numbers and the processor design surely look great, and the product announcement generated plenty of media attention, as has been the norm. The dialogue has shifted, however, as the media has once again seen a new product announcement, but has begun to wonder when these Arm Servers will actually be competetive and ship in any real volumes. This conversation then exploded a few days later, when Linus Torvalds weighed in on the topic, claiming that Arm has already lost, due to the fact that developers and IT teams (for the most part) build and develop on x86 PC’s and workstations, then deploy to the organization’s own servers or the cloud providers. The natural tendency then, is to purchase x86 servers, to match the architecure and eliminate any chance of hardware incompatibility. The x86 PC is, more or less, just a smaller and cheaper version of the exact same server hardware running in the datacenter. Software stacks might vary between local and cloud, but if you can at least minimize differences and just focus on any bugs that may arise due to software variances, that is still better than pushing code up to servers and having to troubleshoot both software AND hardware variances. Thus, the ultimate takeway in Linus’ view, is that until there are cheap, standards-compliant Arm desktop PC’s that developers can use locally, Arm Servers will not stand a chance in the datacenter.

And he is right.

Arm Server enthusiasts have been complaining about this for years, and the product void and differences between the ultra-small and ultra-cheap Arm single board computers (think, Raspberry Pi and similar) and the big, enterprise Arm Servers is too vast. The missing piece in the ecosystem has been a “PC-like” system, that is standards compliant with SBSA and SBBR, and essentially mimics the entire user experience of the x86 PC platforms. This means a normal UEFI boot up and BIOS / GUI that allows user configuration, and a hardware design that allows end users to add whatever hard drives and SSD’s they’d like, choose their brand and size of memory, add in whatever graphics card they prefer, put it all together, and it “just works”. Then, they can install whatever (ARM64) OS they would like, such as RedHat, CentOS, Fedora, Debian, Ubuntu, Suse, etc. Again, it “just works”. The end result is a very “PC-like” experience, and a fully operational Arm desktop computer.

No custom kernels, no board-specific software, no vendor-provided code, no bugs, quirks, hacks, odd shapes and sizes, no fighting with the system, no frustration, and no time spent troublseshooting why the system doesn’t boot or hardware doesn’t work.

Once this is solved, and developers can easily build and test applications and code on an Arm Desktop PC locally, then Arm Servers become a more attractive target to deploy those apps to. Without an Arm Desktop PC, Arm Servers are just a novelty that individuals will continue to test, evaluate, and ultimately discard as not worth the switching costs, as has occured for the past 5 years.

Fortunately, Linus’ timing was excellent, as he spurred this debate just in advance of Linaro Connect, where miniNodes, Packet.net, and Linaro are delivering a joint session titled “Designing a next generation ARM Developer Platform“.  In this talk, we will be discussing this problem in detail, hopefully spurring ideas, investment, and starting the process of correcting the problem and getting a small “NUC-like” Arm product engineered and built. The event is streamed live and recorded, so, tune in and watch if you can!

Hopefully, this is the tipping point, and industry change occurs as a result!

Posted on by — Leave a comment

How to Install Ubuntu Arm Server on the Raspberry Pi Compute Module 3

A few weeks ago, the Ubuntu team released a pre-built 64-bit Ubuntu Arm Server Raspberry Pi image that can be downloaded and flashed to an SD Card, that is compatible with both the Raspberry Pi 3B and Raspberry Pi 3B+ single board computers. As we documented in our original article detailing the new Ubuntu build, in the past you needed to build a kernel, create a root filesystem, and then install the necessary firmware and drivers. But now with this new ready-made image, there is no longer a need for any of those difficult and time consuming tasks. While the image was intended to be run on standard Raspberry Pi 3B and 3B+ hardware, with some small modifications it can be installed and run on the Raspberry Pi Compute Module 3 as well.

First and foremost, you will need to start with the new 64-bit Raspberry Pi 3 Ubuntu Arm Server image, which can be downloaded here: http://cdimage.ubuntu.com/releases/18.04/

Once downloaded, you will need to unzip / extract the image file from the compressed archive file.

Next, using a Raspberry Pi Compute Module IO Board or Waveshare Compute Module IO Board Plus, you will need to flash the image file to the Compute Module 3’s onboard eMMC. Instructions for that process can be found here: https://www.raspberrypi.org/documentation/hardware/computemodule/cm-emmc-flashing.md

After the flash process is complete, there should be 2 partitions on the eMMC, ‘boot’ and ‘system’. Mount the ‘boot’ partition of the eMMC so that you can view and edit the files on it.

The first change to be made is to the ‘config.txt’ file. Open it up and change the kernel line, add an initramfs, add an arm_control line, and comment out the device tree address as such:

kernel=vmlinuz
initramfs initrd.img followkernel
arm_control=0x200
#device_tree_address=0x02000000

Save and exit.

While the partition is still mounted, you need to add an additional file to the top level directory of the partition as well. In this ‘boot’ partition, you will notice there are .dtb files for the Raspberry Pi 3B. But since we are adapting this Ubuntu image for the Compute Module 3, we need to add the CM3’s .dtb file here as well. A copy of the Compute Module 3’s .dtb can be extracted from a stock Raspbian image, but for convenience a copy can be downloaded from the Raspberry Pi GitHub here: https://github.com/raspberrypi/firmware/blob/master/boot/bcm2710-rpi-cm3.dtb

Simply download it, then copy it to the mounted ‘boot’ partition.

At this point, all necessary changes are complete, and it’s time to boot up and check our work! Unmount the ‘boot’ partition, power down the Compute Module, and then change the IO Board to standard boot mode via it’s jumper setting. Reapply power, and the boot process should begin! The first boot takes a few minutes, as cloud-init runs a series of one-time setup processes to resize the rootFS, setup networking, generate SSH keys, create a container environment, and other tasks. But, after a few minutes you should be able to login to your new 64-bit Ubuntu Arm Server for Raspberry Pi Compute Module with a default username and password of ‘ubuntu’ via SSH or a console!