Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘raspberry pi

Out-of-Order Instructions

leave a comment »

Introduction

We think of computer processors executing a set of instructions one at a time in sequential order. As programmers this is exactly what we expect the computer to do and if the computer decided to execute our carefully written code in a different order then this terrifies us. We would expect our program to fail, producing wrong results or crashing. However we see manufacturers claiming their processors execute instructions out-of-order and that this is a feature that improves performance. In this article, we’ll look at what is really going on here and how it can benefit us, without causing too much fear.

Disclaimer

ARM defines the Instruction Set Architecture (ISA), which defines the Assembly Language instruction set. ARM provides some reference implementations, but individual manufacturers can take these, customize these or develop their own independent implementation of the ARM instruction set. As a result the internal workings of ARM processors differs from manufacturer to manufacturer. A main point of difference is in performance optimizations. Apple is very aggressive in this regard, which is why the ARM processors in iPads and iPhones beat the competition. This means the level of out-of-order execution differs from manufacturer to manufacturer, further this is much more prevalent in newer ARM chips. As a result, the examples in this article will apply to a selection of ARM chips but not all.

A Couple of Simple Cases

Consider the following small bit of code to multiply two numbers then load another number from memory and add it to the result of the multiplication:

MUL R3, R4, R5 @ R3 = R4 * R5
LDR R6, [R7]   @ Load R6 with the memory pointed to by R7
ADD R3, R6     @ R3 = R3 + R6

The ARM Processor is a RISC processor and its goal is to execute each instruction in 1 clock cycle. However multiplication is an exception and takes several clock cycles longer due to the loop of shifting and adding it has to perform internally. The load instruction doesn’t rely on the result of the multiplication and doesn’t involve the arithmetic unit. Thus it’s fairly simple for the ARM Processor to see this and execute the load while the multiply is still churning away. If the memory location is in cache, chances are the LDR will complete before the MUL and hence we say the instructions executed out-of-order. The ADD instruction then needs the results from both the MUL and LDR instruction, so it needs to wait for both of these to complete before executing it’s addition.

Consider another example of three LDR instructions:

LDR R1, [R4] @ memory in swap file
LDR R2, [R5] @ memory not in cache
LDR R3, [R6] @ memory in cache

Here the memory being loaded by the first instruction, has been swapped out of memory to secondary storage, so loading it is going to be slow. The second memory location is in regular memory. DDR4 memory, like that used in the new Raspberry Pi 4, is pretty fast, but not as fast as the CPU and it is also loading instructions to process, hence this second LDR might take a couple of cycles to execute. It makes a request to the memory controller and its request is queued with everything else going on. The third instruction, assumes the memory is in the CPU cache and hence processed immediately, so this instruction really does take only 1 clock cycle.

The upshot is that these three LDR instructions could well complete in reverse order.

Newer ARM processors can look ahead through the instructions looking for independent instructions to execute, the size of this pool will determine how out-of-order things can get. The important point is that instructions that have dependencies can’t start and that to the programmer, it looks like his code is executing in order and that all this magic is transparent to the correct execution of the program.

Since the CPU is executing all these instructions at once, you might wonder what the value of the program counter register (PC) is? This register has a very precisely defined value, since it is used for PC relative addressing. So the PC can’t be affected by out-of-order execution. 

Coprocessors

All newer ARM processors include floating-point coprocessors and NEON vector coprocessors. The instructions that execute on these usually take a few instructions cycles to execute. If the instructions that follow a coprocessor instruction are regular ARM instructions and don’t rely on the results of coprocessor operations, then they can continue to execute in parallel to the coprocessor. This is a handy way to get more code parallelism going, keeping all aspects of the CPU busy. Intermixing coprocessor and regular instructions is another great way to leverage out-of-order instructions to get better performance.

Compilers and Code Generation

This indicates that if a compiler code generator or an Assembly Language program rearranges some of their instructions, they can get more things happening at once in parallel giving the program better performance. ARM Holdings contributes to the GNU Compiler Collection (GCC) to fully utilize the optimization present in their reference implementations. In the ARM specific options for GCC, you can select the ARM processor version that matches your target and get more advanced optimizations. Since Apple creates their own development tools under XCode, they can add optimizations specific to their custom ARM implementations.

As Assembly Language programmers, if we want to get the absolute best performance we might consider re-arranging some of our instructions so that instructions that are independent of each other are in a row and hopefully can be executed in parallel. This can require quite a bit of testing to reverse engineer the exact out-of-order instruction capability of your particular target ARM processor model. As always with performance optimizations, you must test the performance to prove you are improving things, and not just making your code more cryptic.

Interrupts

This all sounds great, but what happens when an interrupt happens? This could be a timer interrupt to say your time-slice is up and another process gets to use the ARM Core, or it could be that more data needs to be read from the Wifi or a USB device.

Here the ARM CPU designer has a choice, they can forget about the work-in-progress and handle the interrupt quickly, or they can wait a couple of cycles to let work-in-progress complete and then handle the interrupt. Either way they have to allow the interrupt handler to save the current context and then restore the context to continue execution. Typically interrupt handlers do this by saving all the CPU and coprocessor registers to the system stack, doing their work and then restoring state.

When you see an ARM processor advertised as designed for real-time or industrial use, this typically means that it handles interrupts quickly with minimal delay. In this case, the work-in-progress is discarded and will be redone after the interrupt is finished. For ARM processors designed for general purpose computing, this usually means that user performance is more important than being super responsive to interrupts and hence they can let some of the work-in-progress complete before servicing the interrupt. For general purpose computing this is ok, since the attached devices like USB, ethernet and such have buffers that can hold enough contents to wait for the CPU to get around to them.

A Step Too Far and Spectre

Hardware designers went even further with branch prediction, where if a conditional branch instruction needs to wait for a condition code to be set, they don’t wait but keep going assuming one branch direction (perhaps based on the result from the last time this code executed) and keep going. The problem here is that at this point, the CPU has to save the current state, incase it needs to go back when it guesses wrong. This CPU state was saved in a CPU cache that was only used for this, but had no security protection, resulting in the Spectre attack that figured out a way to get at this data. This caused data leakage across processes or even across virtual machines. The whole spectre debacle showed that great care has to be taken with these sorts of optimizations.

Heat, the Ultimate Gotcha

Suppose your your ARM processor has four CPU cores and you write a brilliant Assembly language program that deploys to use all four cores and fully exploits out-of-order execution. Your program is now using every bit of the ARM CPU, each core is intermixing regular ARM, floating point and NEON instructions You have intermixed your ARM instructions to get the arithmetic unit operating in parallel to the memory unit. This will be the fastest implementation yet. Then you run your program, it gets off to a great start, but then suddenly slows down to a crawl. What happened?

The enemy of parallel processing on a single chip is heat. Everything the CPU does generates a little heat. The more things you get going at once the more heat will be generated by the CPU. Most ARM based computers like the Raspberry Pi assume you won’t be running the CPU so hard, and only provide heat dissipation for a more standard load. This is why Raspberry Pis usually do so badly playing high-res videos. They can do it, as long as they don’t overheat, which typically doesn’t take long.

This leaves you a real engineering problem. You need to either add more cooling to your target device, or you have to deliberately reduce the CPU usage of your program, where perhaps paradoxically you get more work done using two cores rather than four, because you won’t be throttled due to overheating.

Summary

This was a quick overview of out-of-order instructions. Hopefully you don’t find these scary and keep in mind the potential benefits as you write your code. As newer ARM processors come to market, we’ll be seeing larger and larger pools of instructions executed in parallel, where the ability for instructions to execute out-of-order will have even greater benefits.

If you are interested in machine code or Assembly Language programming, be sure to check out my book: “Raspberry Pi Assembly Language Programming” from Apress. It is available on all major booksellers or directly from Apress here.

Written by smist08

November 15, 2019 at 11:11 am

RISC Instruction Encoding

with one comment

Introduction

Modern microprocessors execute programs from memory that are formatted specifically for the processor and the instructions it is capable of executing. This machine code is generated by tools, either fairly directly from Assembly Language source code or via a compiler that translates a high level language to machine code. There are two popular philosophies on how machine code is structured.  One is Reduced Instruction Set Computers (RISC) exemplified by ARM, RISC-V, PowerPC and MIPs processors, and the other is Complex Instruction Set Computers (CISC) exemplified by Intel and AMD processors. In RISC computers, each instruction is quite small and does a tiny bit of work, in CISC computers the instructions tend to be larger and each one does more work. The advantage of RISC processors is that the circuitry is simpler which means they use less power, this is why nearly all mobile devices use RISC processors. In this article we will be looking at some of the tricks RISC computers use to keep their instructions small and quick.

32-Bit Instructions

Most RISC processors use 32-bit machine code instructions. It doesn’t matter if the processor is 32-bit or 64-bits, this only refers to the size of pointers for memory addressing and the size of the registers, in both cases the instructions stay at 32-bits in length. With all rules there are exceptions, for instance in RISC-V processors most instructions are 32-bit, but there is a facility to allow longer instructions where necessary and in ARM processors, in 32-bit mode, there is the ability to limit instructions to 16-bits in length. Modern processors are very powerful and have a lot of functionality, so how do they encode all the information needed for an instruction into 32-bits? This restriction imposes a lot of discipline on the instruction set designers, but the solutions they have come up with are quite interesting. In comparison, Intel x86 instructions are variable length and often 120 bits in length.

Having all the instructions 32-bits in length makes creating an efficient execution pipeline very efficient, since you can load and start working on a set of instructions in parallel. You don’t need to decode one instruction to learn where the next one starts. You know there is a new instruction every 4-bytes in memory. This uniformity saves a lot of complexity and greatly enhances instruction execution throughput.

Where Do the Bits Go?

What needs to be encoded in a machine language instruction? Here are some of the possible components:

  1. The opcode. This tells the processor what the instruction does, whether its add two numbers, load data from memory or jump to another program location. If the opcode takes 8-bits then there are 256 possible instructions. To really save space some opcodes can be less bits, like perhaps if it start 011 then the other bits can go to the immediate value.
  2. Registers. Microprocessors load data into registers and then process the data in the registers. Often two or three registers need to be specified in an instruction, like the two numbers to add and then where to put the result. If there are 32 registers, then each register field will take 5-bits.
  3. Immediate data. Most processors have a way to encode some data in an instruction. Like “LOAD R1, 5” might mean load the value 5 into register R1. Here 5 is data encoded in the instruction, and called an immediate value. The size of these varies based on the instruction and use cases.
  4. Memory Addresses. Data has to be loaded from memory, or program execution has to jump to a different memory location. Note that in a modern computer memory addresses are either 32-bit or 64-bits. These are both too big to fit in a 32-bit instruction (we need at least an opcode as well). In RISC, how do we specify memory addresses?
  5. Bits for additional parameters. Perhaps there are several addressing modes, or perhaps other options for an instruction that need to be encoded. Often there are a few bits in each instruction for this purpose.

 

That’s a lot of information to pack into a 32-bit instruction. How do they do it? My introduction to Raspberry Pi Assembly Language shows how this is done for ARM processors in 32-bit mode.

How to Load a Register

Let’s look at how to load a 32-bit register with data. We can’t fit a full 32-bit value inside a 32-bit instruction, so what do we do? You might suggest that we load the value from memory rather than encode the value in the instruction. This is a legitimate thing to do, but it just moves the problem since we now need to load the 32 or 64-bit memory address into memory first.

First we could do it in two steps, perhaps we can fit a 16-bit value in an instruction and then perform two load instructions to load the value. In an ARM processor, there is a MOV instruction that can load a 16-bit immediate value and then a MOVT instructions that loads a 16-immediate value into the top 16-bits of a register. Suppose we want to load 0x12345678 into register R1, then in ARM 32-Bit Assembly we would encode:

MOVT R1, #0x1234
MOV  R1, #0x5678

This works and we do expect that working in RISC is going to take lots of small instructions to perform the work we need to get done. However this is somehow not satisfying, since this is something we do a lot and it seems wasteful to take two instructions. The other thing is that if we are running 64-bit mode and want to load a 64-bit register then this will take 4 instructions.

Another trick is to make use of the Program Counter (PC) register. This register points to the instructions currently being executed. So if we can position the value near this then we could load it by dereferencing the PC (plus a small offset). As long as the offset fits in the amount of room we have for an immediate value then this could work. In the ARM world, the Assembler helps us generate this code. We write something like:

LDR R1, =mydata

...

mydata: .WORD 0x12345678

Then the Assembler will convert the LDR instruction to something like:

LDR R1, [PC, #20]

Which means load the data pointed to by PC + 20 into R1. Now it only takes one instruction to load the data.  This technique has the advantage that it will remain one instruction to execute when dealing with 64-bit data.

Summary

This was a quick discussion of how RISC processors encode each machine code instruction as a 32-bit value. This is one of the key things that keeps RISC processors simple, allowing them to be quick while at the same time simple, and hence more power efficient.

If you are interested in machine code or Assembly Language programming, be sure to check out my book: “Raspberry Pi Assembly Language Programming” from Apress. It is available on all major booksellers or directly from Apress here.

Written by smist08

November 8, 2019 at 11:55 am

Raspberry Pi Assembly Language Programming

leave a comment »

 

Introduction

My new book “Raspberry Pi Assembly Language Programming” has just been published by Apress. This is my first book to be published by a real publisher and I’m thrilled to see it appearing on websites of booksellers all over the Internet. In this blog post I’ll talk about how this book came to exist, the process of writing and publishing it and a bit about the book itself.

For anyone interested in this book, here are a few places where it is available:

Most of these sites let you see a preview and the table of contents.

This blog’s dedicated page to my book.

How this Book Came About

I purchased my Raspberry Pi 3+ in late 2017 and had a great deal of fun playing with it. I wrote quite a few blog posts on the Pi, a directory of these is available here. The Raspberry Pi package I purchased included a breadboard and a selection of electronic components. I put together a set of LEDs connected to the Pi’s GPIO ports. I then wrote a series of articles on making these LEDs flash using various programming languages including C, Python, Scratch, Fortran, and Erlang. In early 2018 I was interested in learning more about how the Pi’s ARM processor works and delved into Assembly language programming. This resulted in two blog posts, an introduction and then my flashing LED program ported to ARM Assembly Language.

Earlier this year I was contacted by an Apress Talent Acquisition agent who had seen my blog articles on ARM Assembly Language and wanted to know if I wanted to develop them into a book. I thought about it over the weekend and was intrigued. The material I found when writing the blog articles wasn’t great, and I felt I could do better. I replied to the agent and we had a call to discuss the book. He had me write up a proposal and possible table of contents. I did this, Apress accepted it and sent me a contract to sign.

The Process

Apress provided a Word style sheet and a written style guide. My writing process has been to write in Google Docs and then have my spouse, a professional editor, edit it. The collaboration of Google Docs is just too good to do away with. So I wrote the chapters in Google Docs, got them edited and then transferred them to MS Word and applied the Apress style sheet.

I worked with a coordinating editor at Apress who was very energetic in getting all the pieces done. She found a technical editor who would provide a technical review of each chapter as I wrote it. He was located in the UK, so often I would submit a chapter and see it edited overnight.

Once I had submitted all the chapters then a senior development editor gave the whole book a review. At that point I thought I was done, but then the book was given to Springer’s (Apress’s parent company) production department who did another editing pass. I was surprised that the production department still found quite a few things that needed fixing or improving.

After all that the book appeared fairly quickly. I like the cover, they used my photo of my breadboard with the flashing LEDs. As of today, the book is available at most booksellers, some with stock and some on preorder. I signed the contract in June and did the bulk of the writing in July and August. Overall, I’m pretty happy with the process and how things turned out.

The Book

My philosophy was to introduce complete working programs from Chapter 1 with the traditional “Hello World” program. I only covered topics where you could write the code with the tools included with the Raspberry Pi and run them. I lay the foundations for how to write larger Assembly programs, with how to code the various structured programming constructs, but also include a chapter on how to interoperate with C and Python code.

Raspbian is a 32-bit operating system as older Raspberry Pi’s and the Raspberry Pi Zero can only run 32-bit code. I didn’t want to leave out 64-bit code, as there are 64-bit versions of Linux from other distributions like Ubuntu that are available for the Pi. So I included a chapter on ARM 64-bit Assembly along with guidelines on how to port your 32-bit code to 64-bit. I then included 64-bit versions of several of the programs we had developed along the way.

There is a lot of interest in ARM Assembly Language, especially from hackers, as all phones, tablets and even a few laptops are running ARM processors now. I included a number of hacking related topics like how to reverse engineer code, as security professionals are very interested in this as they work to protect the mobile devices utilized by their organizations.

The ARM Processor is a good example of a RISC processor, so if you are interested in RISC, this book will give a good introduction to the concepts, like how to do everything with instructions that are only 32-bits in length. Once you understand ARM Assembly, picking up the Assembly language of another RISC processor like the Risc-V becomes much easier.

The book also covers how to program the floating point processor included with most ARMs along with the NEON vector processor that is available on newer Raspberry Pis.

Summary

If you are interested in learning Assembly Language, please check out my book. The Raspberry Pi provides a great platform to do this. Even if you only program in higher level languages, knowing Assembly Language will help you understand what is going on at a deeper level. How modern processors design their Assembly Language to maximize program performance and minimize memory usage is quite fascinating and I hope you find the topic as interesting as I do.

 

Written by smist08

November 1, 2019 at 11:22 am

The Race for 64-Bit Raspberry Pi 4 Linux

leave a comment »

Introduction

When the Raspberry Pi 4 was announced and shipped this past June, it caught everyone by surprise. No one was expecting a new Pi until next year sometime, if we were lucky. The Raspberry Pi 4 has updated faster components, including an updated ARM processor and USB 3.0. Raspbian, the official version version of Linux for the Pi was updated to be based on Debian Buster and shipped before the official Debian Buster actually shipped. However, Raspbian is still 32-bit, where the Raspberry foundation say this is so they only have to support one version of Linux for all Raspberry Pi devices.

Others in the Linux community, have then figured out how to run 64-bit Linux’s on the Raspberry Pi. For instance there are 64-bit versions of Ubuntu Mate, Ubuntu Server and Kali Linux. These work on the Raspberry Pi 3, but due to changes in the Raspberry architecture, didn’t work on the Raspberry Pi 4 when it shipped. We still don’t have official 64-bit releases, but we are reaching the point where the test builds are starting to work quite well.

Why 64-Bit?

To be honest, 64-bit Linux never ran very well on the Raspberry Pi 3. 64-bit Linux and 64-bit programs requires quite a bit more memory than their 32-bit equivalents. Each memory address is now 64-bits instead of 32-bits and there is a tendency to use 64-bit integers rather than 32-bit integers. The ARM processor instructions are 32-bits in both 32-bit and 64-bit mode, so programs tend to be about the same size, though 64-bit doesn’t have use of the 16-bit ARM thumb instructions. The Raspberry Pi 3 is limited to 1Gig of memory, that can just barely run a 64-bit Linux, and tends to run out of memory quickly as you run programs, like web browsers. The Raspberry Pi 4 now supports up to 4Gig of memory and that is sufficient to run 64-bit Linux along with a respectable number of programs. Plus the Raspberry Pi 4 has faster access to the SDCard and USB 3, so you can attach an even faster external drive, so if you do get swapping, it isn’t as painful.

In spite of these limitations, there are reasons to run 64-bit. The main one is that you can get better performance, especially if you actually need to work with 64-bit integers. Further the 64-bit instruction set has been optimised to work better with the execution pipeline, so you don’t get as many stalls when you perform jumps. For instance in 32-bit ARM, there is no function return instructions, so people use regular branches, pop the return address from the stack directly into the program counter or do a number of other tricks. As a result, function returns causes the execution pipeline to be flushed. In 64-bit, the pipeline knows about return instruction and knows where to get the next few instructions.

If 64-Bit Worked on the Pi 3, What’s the Problem?

If we had 64-bit working for the Pi 3, why doesn’t it just work on the Pi 4? There are a few reasons for this. The first obstacle was that Raspberry changed the whole Pi boot process. The Raspberry Pi 3 booted using the GPU. When it started the Pi 3’s GPU runs a program that knows how to read the boot folder on an SDCard and will load this into memory and then start the ARM CPU to run what it loaded into memory. The Raspberry Pi 4 now has a slightly larger EEPROM, this contains ARM code that executes on startup and then loads a further step from the SDCard. The volunteers with the other Linux distributions had to figure out this new process and adapt their code to fit into it. Sadly, the original EEPROM program didn’t provide a good way to do this, so the Linux volunteers have been working with Raspberry to get the support they need in newer versions of the EEPROM software. The most recent version seems to be working reliably finally.

The Raspberry Pi 4 then has all new hardware, so new drivers are required for bluetooth, wifi and everything else. To keep the price down, Raspberry uses older standard components, so there are drivers already written for all these devices. It’s just a matter of including the correct drivers and providing default configurations that work and settings dialogs if anything might need user input. This is all being worked on in parallel, and the consensus is that we are already in a better place than we were for the Pi 3.

It’s All Open Source so Why not Copy from Rasbian?

The Raspbian kernel is open source so anyone can look at that source code, but the EEPROM firmware is not open source. This can be reverse engineered, but that takes time. The Raspberry Pi foundation has been quite helpful in supporting people, but that is no substitute for reading the source code. This again shows the importance of open source BIOS.

Development got off to a slow start, because the Raspberry Pi foundation didn’t give anyone a heads up that this was coming. The developers of Ubuntu Mate had to order their Raspberry Pi 4’s just like everyone else when the announcement happened. This meant no one really got started until into July.

In spite of claiming up and down that they will never produce a 64-bit version of Raspbian, the Raspberry Pi foundation has produced a test Raspbian 64-bit Linux kernel. This then tests out that the Raspberry Pi firmware will support 64-bits and that all the device drivers are available. I couldn’t get this kernel to work, but it is proving very helpful for other developers. It also makes people excited that maybe Raspbian will go 64-bit sooner than later.

How Are We Doing?

The first distribution to get all this going is Gentoo Linux. They have a very smart developer Sakaki who provided the first image that actually worked. This then led to Arch and Majaro Linux releases based on Gentoo. This was a good first step, though these distributions are more for the DIY crowd due to their preference to always installing software from source code.

Next James Chambers put together a guide and images to allow you to install Ubuntu Server 64-bit on the Pi 4. Ubuntu Server is character based, but installing a desktop is no problem. The main limitation of this release is that you need a hardwired Internet connection to start. You can’t start with Wifi as the Wifi software isn’t installed with the base image. If you do have a wired Internet connection, getting it installed and installing the desktop is quite straightforward and works well. Once you have the desktop installed, then you can configure Wifi and ditch the ethernet cable.

The changes required for the Raspberry Pi 4 are being submitted to the standard Linux kernel for version 5.4. When this ships it will have available drivers for the Pi 4 hardware and official support for the Broadcom chips used in the Pi. Version 5.3 of the Linux kernel just shipped and added support for the NVidia Jetson Nano. Hopefully the wait for Linux 5.4 won’t be too long.

Summary

I’ve been running the 64-bit version of Ubuntu Linux Server, with the Xubuntu desktop for a few days now and it works really well on my Raspberry Pi 4 with 4Gig of RAM. Performance is great and everything is working. I’ve installed various software, including CubicSDR which works great. This is the first time I’ve been happy with Software Defined Radio running on a Pi.

I look forward to the official releases, and given the state of the current builds, think we are getting quite close.

Written by smist08

September 20, 2019 at 6:38 pm

Raspberry Pi 4 as a Desktop Computer

leave a comment »

Introduction

The Raspberry Pi Foundation is promoting the Raspberry Pi 4 as a full desktop computer for only $35. I’ve had my Raspberry Pi 4 for about a month now and in this article we’ll discuss if it really is a full desktop computer replacement. This partly depends on what you use your desktop computer for. My answer is that the $35 price is misleading, you need to add quite a few other things to make it work well.

Making the Raspberry Pi 4 into a Decent Desktop

The Raspberry Pi has always been a barebones computer. You’ve always needed to add a case, a keyboard, a mouse, a monitor, a power supply, a video cable and a microSD card. Many people already have these kicking around, so they don’t need to buy them when they get their Pi. For instance, I already had a keyboard and monitor. The Raspberry Pi 4 even supports two monitors.

Beyond the bare bones, you need two more things for a decent desktop, namely:

  1. The 4GB version of the Raspberry Pi 4
  2. A good USB SSD drive

With these, it starts to feel like you are playing with a regular desktop computer. You now have enough RAM to run multiple programs and any good SSD will greatly enhance the performance of thee system, only using the microSD card to boot the Pi.

The Raspberry Pi 3 is a great little computer. Its main limitation is that if you run too many programs or open too many browser tabs, it bogs down and you have a painful process of closing windows (that aren’t responding well), until things pick up again. Now the Raspberry Pi 4 with 4GB of RAM really opens up the number of things you can do at once. Running multiple browser tabs, LibreOffice and a programming IDE are no problem.

The next thing you run into with the Raspberry Pi 4 is the performance of the SD card. Since I needed a video cable and a new case, I ordered a package deal that also included a microSD card containing Raspbian. Sadly, these bundled microSD cards are the cheapest, and hence slowest available. Having Raspbian bundled on a slow card is just a waste. Switching to a Sandisk Extreme 64GB made a huge difference. The speed was much better. When buying a microSD card watch the speed ratings, often the bigger cards (64GB or better) are twice as fast as the smaller cards (32GB or less). With a good microSD card the Raspberry Pi 4 can read and write microSD twice as fast as a Raspberry Pi 3.

I’ve never felt I could truly trust running off a microSD card. I’ve never had one fail, but people report problems all the time. Further, the performance of microSD cards is only a fraction of what you can get from good SSDs. The Raspberry Pi 4 comes with two USB 3 ports which have a theoretical performance ten times that of the microSD port. If you shop around you will find M.2 and SATA SSDs for prices less than those of microSD cards. I purchased a Kingston A1000 M.2 drive which was on sale cheap because the A2000 cards just started shipping. I had to get an M.2 USB caddy to contain it, but combined this was less than $100 and USB caddies are always useful.

Unfortunately, you can’t boot the Raspberry Pi 4 directly off a USB port yet. The Raspberry Pi foundation say this is coming, but not quite here yet. What you can do is have the entire root file system on the USB drive, but the boot partition must be on a microSD card. Setting up the SSD was easier than I thought it would be. I had to partition it, format it, copy everything over to the SSD and then edit /boot/config.txt to say where the root of the main file system is.

With this done, I feel like I’m using a real desktop computer. I’m confident my data is being stored reliably, the performance is great.

Overheating

The Raspberry Pi 4 uses more power than previous Pis. This means there is more heat to dissipate. The case I received with my Pi 4 didn’t have any ventilation holes and would get quite hot. I solved the problem by removing the top of the case. This let enough heat out that I could run fine for most things. People report that when using a USB SSD that the USB controller chip will overheat and the data throughput will be throttled. I haven’t run into this, but it is something to be aware of.

I installed Tensorflow, Google’s open source AI toolkit. Training a data model with Tensorflow does make my Pi 4 overheat. I suspect Tensorflow is keeping all four CPU cores busy and producing a maximum amount of heat. This might drive me to add a cooling fan. I like the way the Pi runs so quietly, with no fan, it makes no noise. I might try using a small fan blowing down on the Pi to see is that helps.

Summary

Is the Raspberry Pi 4 a complete desktop computer for $35? No. But if you get the 4GB model for $55 and then add a USB 3 SSD, then you do have a good workable desktop computer. The CPU power of the Pi has been compared to a typical 2012 desktop computer. But for the cost that is pretty good. I suspect the Wifi/Lan and SSD are quite a bit better than that 2012 computer.

Keep in mind the Raspberry Pi runs Linux, which isn’t for everyone. A typical low cost Windows desktop goes for around $500 these days. You can get a refurbished one for $200-$300. A refurbished desktop can be a good inexpensive option.

I like the Raspberry Pi, partly because you are cleanly out of the WinTel world. No Windows, no Intel. The processor is ARM and the operating system is Raspbian based on Debian Linux. A lot of things you do are DIY, but I enjoy that. With over 25 million Raspberry Pis sold worldwide, there is a lot of community support and you join quite an enthusiastic thriving group.

Written by smist08

August 26, 2019 at 8:17 pm

Raspberry Pi 4 First Impressions

leave a comment »

Introduction

I’ve received my Raspberry Pi 4B with 4GB or RAM a few weeks ago. I’ve been using it to write my forthcoming book on Raspberry Pi Assembly Language Programming, so I thought I’d give a few of my first impressions. The biggest change for the Raspberry Pi 4 is the support for three memory sizes, 1GB, 2GB and 4GB. This overcomes the biggest complaint against the Raspberry Pi 3, that it bogs down too quickly as you run browser tabs and multiple windows.

Some of the other hardware improvements are:

  • Dual 4K monitor support with dual micro-HDMI ports.
  • Two of the four USB ports are USB-3.
  • The ethernet is now gigabit and the WiFi is faster.
  • A 1.5GHz quad-core 64-bit ARM Cortex-A72 CPU.
  • The SDRAM is now LPDDR4.
  • The GPU is upgraded to Broadcom’s VideoCore VI.
  • Hardware HEVC video support for 4Kp60 video.

On paper, this makes the Raspberry Pi 4 appear far superior to its predecessors, In this article, I’ll discuss what is much better and a few of the drawbacks. This release will squash a lot of the compatible Pi competitors, but I’ll compare it to my NVidia Jetson Nano and mention a few places where these products still surpass the Pi.

Raspbian Buster

At the same time the Raspberry Pi Foundation released the Raspberry Pi 4, they also released the new “Buster” version of Raspbian, the Debian Linux derived operating system tailored specifically to the Raspberry Pi. On the day this was announced, I ordered my Raspberry Pi 4, then went and downloaded the new Buster release, then installed it on my Raspberry Pi 3B.

If you have a Raspberry Pi 4, then you must run the Buster release as older versions of Raspbian don’t have support for the newer hardware. If you are running an older Pi then you can keep running the older version or upgrade as you like.

Is it 64-Bits?

The first rumour that was squashed was that Raspbian would move to 64-bits. This didn’t happen. Raspbian is a 32-bit operating system. The Raspberry Pi Foundation says it will stay this way for the foreseeable future. The first reason is that the Raspberry Pi 1 and Raspberry Pi Zero use a much older ARM processor that doesn’t support 64-bits. The Raspberry Pi Foundation still supports and sells these models and they are quite popular due to their low price. They don’t want to support two operating systems, so they stick to one 32-bit version that will run on every Raspberry Pi ever made. Perhaps other hardware vendors should look at this level of support for older models.

Even though 32-bit implies a 32-bit virtual address space for processes, which limits an individual process to 4GB of memory, the ARM SoC used in the Pi has memory access hardware for 48-bit addresses. This allows the operating system to give each process a different 4GB address space, so if Raspberry Pi models with more than 4GB of memory are released, Raspbian can utilize this memory.

Another problem with going to 64-bits is that all the previous Raspberry Pi models, and one version of the Raspberry Pi 4 only have 1GB of RAM. This isn’t sufficient to run a 64-bit operating system. You can do it, but the operating system takes all the RAM, and once you run a program or two, everything bogs down. This is due to all addresses and most integers becoming 64-bits, and hence twice as large. A definite nice feature of Raspbian is that it can run effectively in only 1GB or memory.

Based on Debian Buster

Raspbian is notorious for lagging behind the mainstream releases of Linux. The benefit of this is that Raspbian has always been very stable and reliable. It works well and avoids the problems that happen at the bleeding edge. The downside is that it can contain security vulnerabilities or bugs that are fixed in the newer versions.

With Buster, Raspbian released its version ahead of Debian releasing the main version. Linus Torvalds himself was involved in moving the Pi up to a newer version of the Linux kernel. His concern is that as other hardware platforms adopt proprietary software like UEFI firmware, with government mandated backdoors, that the benefits of open source are being lost. The Raspberry Pi, including its firmware are all open source and there is a feeling in the open source community that this is the future to fight for.

Some Software Not Ported Yet

As a result of the move to Buster, some software that Raspberry users are accustomed to is missing. The most notable case is Mathematica. A port of this is underway and it is promised to be included in a future upgrade.

I had problems with CubicSDR, a Software Defined Radio (SDR) program. It could detect my SDR USB device, but didn’t run properly, just displaying a blank screen when receiving.

Heat Dissipation

The Raspberry Pi 4 uses more power than previous models. It requires a USB-C power adapter which means you can’t use a power adapter from previous models. I bought my Pi 4 from buyapi.ca and got the bundle with a case, power adapter, heat sinks and micro-HDMI cable. I needed the cables. The case is their Raspberry Pi 3 case, with the holes for the cables moved for the slightly different Pi 4 configuration. The case lacked any ventilation holes and the Pi would throttle due to overheating fairly easily. My solution was to run it with the top of the case removed. This seems to provide enough air circulation that I haven’t seen any overheating since.

Some people claim the Raspberry Pi 4 requires a fan for cooling, but that hasn’t been my experience. I think the cases need properly thought out ventilation and that is all that is needed. I think a bigger heatsink like the one included with the NVidia Jetson Nano would be warranted as well. I don’t like fans and consider the quietness of the Pi as one of its biggest features.

Cons

All this sounds great, but what are the downsides of the Raspberry Pi 4?

All New Cables

I purchased an NVidia Jetson Nano and to run it, I just unplugged the cables from my Raspberry Pi 3 and plugged them into the Jetson and away it went. Not new cables required.

The Raspberry Pi required a new USB-C power supply and a lot has been made of how you can’t use Apple laptop power supplies, but I think the real issue is you can’t use an older Pi power supply, even if it can provide sufficient power.

To support dual monitors, the Pi went to micro-HDMI ports to fit both connectors. This means you need either new cables or at least micro- to regular-HDMI adapters. The NVidia Jetson supports dual monitors but annoyingly with two different cables, HDMI and a DisplayPort cable. At least the cables are the same for the two video ports.

Otherwise all my USB devices that I was using with the Raspberry Pi 3 seem to work with the Pi 4.

SDCard Bottleneck

They have improved the data transfer speed to and from the microSD card with the Pi 4, but this is still a bottleneck. I would have loved it if they had added a M.2 SSD interface to the board. You can improve on the microSD card speed by using a USB 3 external SSD. The problem is that you can’t boot from this USB 3 drive. You can copy the root filesystem over to the drive and run mostly from the USB and although I haven’t tried it yet, people report this is an improvement.

Raspberry Pi promote the 4 as a desktop computer replacement and it definitely has the processing power. However, I don’t think this really holds up without something better than running off a microSD card. The Raspberry Pi Foundation say they will add boot from USB support in a future firmware update, but it isn’t there yet. Although the speed of USB 3 is better than the microSD interface, it still isn’t nearly as good as you can obtain with M.2 and a good new SSD.

No 64-Bits Yet

The Raspberry Pi Foundation, caught everyone by surprise with their release. This included the people that maintain alternate operating systems for the Raspberry Pi. There is a good Ubuntu Mate 64-bit version that runs on the Raspberry Pi 3. It is slow and you can’t run many programs, but it does work and you can experiment with things like ARM 64-bit Assembly programming.

The person that maintains this had to order his Raspberry Pi 4, like everyone else and hasn’t produced a Pi 4 version yet. It would have been nice if the Raspberry Pi Foundation had seeded some early models to the people that develop alternate operating systems for the Pi.

As of this writing, Raspbian is the only operating system that runs on the Raspberry Pi, but hopefully the others won’t take too long to modify what they need to.

The Raspberry Pi 4 with 4GB is the first Raspberry Pi that has the power to run a true 64-bit operating system, so it would be nice to play with.

Cost

The Raspberry Pi 4 is still dirt cheap, $35 for the 1GB model and $55 for the 4Gig model. This upgrade is a bit more expensive since you need a new power adapter, new video cables and a new case as well. I think the extra $20 for the extra memory is well worth it.

Compared to the NVidia Jetson Nano

The Raspberry Pi 4 blows most of the current crop of Pi clones out of the water. One exception is the NVidia Jetson Nano. This single board computer has 4GB of memory and runs full 64-bit Ubuntu Linux and as a consequence feels more powerful than the Pi 4.

The Pi 4 has a more powerful ARM CPU, but the Jetson has 4 USB-C ports and a 128 core CUDA GPU. The CUDA GPU is used by software like CubicSDR for DSP like processing, along with most AI toolkits like Tensorflow.

The NVidia Jetson costs $99, so is nearly twice as expensive as a Pi 4. However if you want to experiment with AI, the 128-core CUDA GPU is an excellent entry level system. 

Summary

I got used to the Raspberry Pi 4 fairly quickly and after a couple of weeks thought it was pretty similar to the Raspberry Pi 3. I then needed to do something on my Raspberry 3 and booted it up. After using the Pi 4, going back to the Pi 3, felt like I was working in molasses, everything was so slow. This is a real testament to how good the new Pi is, especially with 4GB of memory.

Yes, there are some teething problems with the new model, as there often is at the bleeding edge. But overall the Raspberry Pi 4 is a solid upgrade, and once you adopt it, you really can’t go back. 

 

Written by smist08

August 2, 2019 at 7:09 pm

Can NVidia Bake a Better Pi Than Raspberry?

with 4 comments

Introduction

I love my Raspberry Pi, but I find it’s limited 1Gig of RAM can be quite restricting. It is still pretty amazing what you can do with these $35 computers. I was disappointed when the Raspberry Foundation announced that the Raspberry Pi 4 is still over a year away, so I started to look at Raspberry Pi alternatives. I wanted something with 4Gig of RAM and a faster ARM processor. I was considering purchasing an Odroid N2, when I saw the press release from NVidia’s Developer Conference that they just released their NVidia Jetson Nano Developer Kit. This board has a faster ARM A57 quad core processor, 4 Gig of RAM plus the bonus of a 128 core Maxwell GPU. The claim being that this is an ideal DIY computer for those interested in AI and machine learning (i.e. me). It showed up for sale on arrow.com, so I bought one and received it via FedEx in 2 days.

Setup

If you already have a Raspberry Pi, setup is easy, since you can unplug things from the Pi and plug them into the Nano, namely the power supply, keyboard, monitor and mouse. Like the Pi, the Nano runs from a microSD card, so I reformatted one of my Pi cards to a download of the variant of Ubuntu Linux that NVidia provides for these. Once the operating system was burned to the microSD card, I plugged it into the Nano and away I went.

One difference from the Pi is that the Nano does not have built in Wifi or Bluetooth. Fortunately the room I’m setting this up in has a wired Internet port, so I went into the garage and found a long Internet cable in my box of random cables, plugged it in and was all connected to the Internet. You can plug a USB Wifi dongle in if you need Wifi, or there is an M.2 E slot (which is hard to access) for an M.2 Wifi card. Just be careful of compatibility, since the drivers need to be compiled for ARM64 Linux.

The board doesn’t come with a case, but the box folds into a stand to hold the board. For now that is how I’m running. If they sell enough of these, I’m sure cases will appear, but you will need to ensure there is enough ventilation for the huge heat sink.

Initial Impressions

The Jetson Nano certainly feels faster than the Raspberry Pi. This is all helped by the faster ARM processor, the quadrupled memory, using the GPU cores for graphics acceleration and that the version of Linux is 64 Bit (unlike Raspbian which is 32 Bit). It ran the pre installed Chromium Browser quite well.

As I installed more software, I found that writing large amounts of data to the microSD card can be a real bottleneck, and I would often have to wait for it to catch up. This is more pronounced than on the Pi, probably because other things are quite slow as well. It would be nice if there was an M.2 M interface for an NVMe SSD drive, but there isn’t. I ordered a faster microSD card (over three times faster than what I have) and hope that helps. I can also try putting some things on a USB SSD, but again this isn’t the fastest.

I tried running the TensorFlow MNIST tutorial program. The version of TensorFlow for this is 1.11. If I want to try TensorFlow 2.0, I’ll have to compile it myself for ARM64, which I haven’t attempted yet. Anyway, TensorFlow automatically used the GPU and executed the tutorial orders of magnitude faster than the Pi (a few minutes versus several hours). So I was impressed with that.

This showed up another gotcha. The GPU cores and CPU share the same memory. So when TensorFlow used the GPU, that took a lot of memory away from the CPU. I was running the tutorial in a Jupyter notebook running locally, so that meant I was running a web server, Chromium, Python, and then TensorFlow with bits on the CPU and GPU. This tended to use up all memory and then things would grind to a halt until garbage collection sorted things out. Running from scratch was fine, but running iteratively felt like it kept hitting a wall. I think the lesson here is that to do machine learning training on this board, I really have to use a lighter Python environment than Jupyter.

The documentation mentions a utility to control the processor speeds of the ARM cores and GPU cores, so you can tune the heat produced. I think this is more for if you embed the board inside something, but beware this sucker can run hot if you keep all the various processors busy.

How is it so Cheap?

The NVidia Jetson Nano costs $99 USD. The Odroid is $79 so it is fairly competitive with other boards trying to be super-Pis. However, it is cheaper than pretty much any NVidia graphics card and even their Nano compute board (which has no ports and costs $129 in quantities of 1000).

The obvious cost saving is no Wifi and no bluetooth. Another is the lack of a SATA or M.2 M interface. It does have a camera interface, a serial interface and a Pi like GPIO block.

The Nano has 128 Maxwell GPU cores. Sounds impressive, but remember most graphics cards have 700 to 4000 cores. Further Maxwell is the oldest supported platform (version 5) where as the newest is the version 7 Volta core.

I think NVidia is keeping the cost low, to get the DIY crowd using their technologies, they’ve seen the success of the Raspberry Pi community and want to duplicate it for their various processor boards. I also think they want to be in the ARM board game, so as better ARM processors come out, they might hope to supplant Intel in producing motherboards for desktop and laptop computers.

Summary

If the Raspberry Pi 4 team can produce something like this for $35 they will have a real winner. I’m enjoying playing with the board and learning what it can do. So far I’ve been pretty impressed. There are some limitations, but given the $100 price tag, I don’t think you can lose. You can play with parallel processing with the GPU cores, you can interface to robots with the GPIO pins, or play with object recognition via the camera interface.

For an DIY board, there are a lot of projects you can take on.