Archive

Archive for November 17, 2016

Build NodeJS from Source

November 17, 2016 Leave a comment
nodeJS rocks!

nodeJS rocks!

Since your Smart Mobile Studio programs can run from Linux under Raspberry PI, I figured I could write a few words about building from C/C++ source. Normally you don’t need to do this, but in case the process-manager (which makes sure your Smart NodeJS servers can be clustered and essentially controlled as services) can be picky about the version – you may suddenly find yourself needing the cutting edge.

Open up a command-line prompt and CD (change dir) to the location you want to keep node. Since this is so essential to my system I keep it at root (/), but you may want to stuff it in your home folder.

Either way, cd to the location then do:

sudo apt-get install build-essential
sudo apt-get install curl openssl libssl-dev

Odds are this is up to date (it was on my fresh Raspbian image). If not, let it finish (you may need to press “y” at some point) and let it work itself out.

You also need to install git (may also already be there):

sudo apt-get install git

With those in place, let’s do a clone of the node.js repository:

git clone https://github.com/nodejs/node.git

When its finished you should have a “nodejs” folder available. So we cd into that and do a configure:

cd node
./configure
make
sudo make install

Now building anything on the Raspberry PI is slow. So the “make” call will probably take 1.5 hours depending on your PI. If its overclocked you will probably get away with 45 minutes, but a bog standard Raspberry PI 3 is much slower.

When it’s all done, test it with

node --version

As of writing that prints out “8.0.0-pre” since im using the cutting edge pre-release version right now.

Now you can install npm (node package manager)¬†and them pm2 and enjoy the show ūüôā

Overclocking the Raspberry PI 3

November 17, 2016 2 comments

On the menu for today was a meeting with my partner in crime, Glenn, who is working hard on the Raspberry PI Linux distro for Smart Mobile Studio – and then do some Linux stuff. For the Smart Pascal headers to actually fit the latest stuff I needed (doh) the latest version of Node to test on. Which has to be built from C/C++ source code on the Arm device.

Building purely from C/C++ source on a PI is .. probably the worst thing I did all day. Cross-compile from your PC instead

Building purely from C/C++ source on a PI is .. probably the worst thing I did all day. Cross-compile from your PC instead

So I baked a fresh copy of Raspbian with the sexy new Pixel UI, updated packages and so on. I set the CPU in performance mode (yes the CPU has different modes) before doing a compile — installed git, cloned out the latest nodejs repository and hit configure + make.

Well, its been 60+ minutes since the bloody build started so I thought, hey why not overclock the sucker and at least shave some off the waiting. But sadly overclocking is not supported by the official Raspbian system settings.

After a bit of google time I found a guy that had gone through the ropes and settled on a sexy 1400 frequency overclock with an over-voltage at around 6. This is stable and the core temp when spawning 4 intense 100% threads (one for each core) is around 58-60 degrees. In other words, well within the specifications (the cpu blows at around 80 degrees and will also kick the bucket at -40).

15102074_10153963465515906_1574367388_o

The dark side of the force is a pathway to many abilities, some considered unnatural

So — you do this at your own risk. Do not attempt this unless you understand the risk. By overclocking you can kiss the warranty good-bye, and I take NO RESPONSEBILITY for whatever damage or loss this could cause. You are on your own when you overclock anything, be it your dishwasher, PC or Raspberry PI embedded boards.

Having said that, the worst that can happen is that you kill your PI. Not exactly a heart breaking loss since they retail at around $35. In most cases when a CPU gets to warm it just shuts down or programs crash. So should that happen let it cool, then use a normal image and leave overclocking alone.

Heat sinks

Yes it may look silly, but if you overclock anything you need to delegate the extra heat somewhere. You can get a heat-sink set for around $1-$3 depending on the vendor. I ordered a couple of sets from Asia at around $2. You get the same kit at RC components for roughly the same price.

Tiny little things with double-sided sticky tape. Works like a charm.

Tiny little things with double-sided sticky tape. Works like a charm.

Ironically it’s not just the CPU that overheat, but also the USB controller and WIFI chip. Thats why a trim-set typically ships with 3 mini heat sinks.

Let there be light!

Boot your PI with a normal raspberry image (and take a backup in case of karma). When you get to the desktop, open a command-prompt and cd all the way back to root (/). Then cd into the boot folder. Inside the boot folder you will find a file called “config.txt”. You need to edit this file with admin rights:

sudo nano config.txt

This opens up nano, a dos like text editor. Just scroll down until you find:

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

Change that to the following:

#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=1400
over_voltage=6

hit CTRL+x, when asked if you want to save – hit “y”. The file is now saved and the next time you boot – it should run at 1.45 GHz. Which is quite¬†nice

To reboot, just type

reboot

This is the setting that works best for me:

#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=1350
over_voltage=5
sdram_freq=500
gpu_freq=500

The sdram overclocking might not work at all (did for me though), and some PI’s actually wont run any faster above arm_freq=1300, but mine works fine with the above settings.

From 3 FPS to 7 FPS! We are talking millions of pixels per frame, and going from 3 to 7 FPS is quite a boost!

Click for video!!! From 3 FPS to 7 FPS! We are talking millions of pixels per frame, and going from 3 to 7 FPS is quite a boost!

Also note that if it wont boot, just plug the sd-card into your PC and edit the config.txt there in notepad (the boot folder on the pi is actually a mapping to the windows fat32 partition).

Remember to fit the heat-sinks BEFORE you boot (!)

Updated

Since some guy has posted “you dont understand the raspberry PI” in the comment section I just want to respond to that briefly.

Yes, you are partly right, there are aspects of the PI I dont have a clue about. Nor do I pretend to be guru about every piece of tech i come into contact with (that would be a very booring life IMHO). In fact, what I think is exciting about that little machine is that you can tinker and learn as you go –¬†and that even mid-level users like myself can get results.

The JavaScript demo I used to test the clocking is actually a reasonable starting point. At first it was running at roughly 1 fps (due to poor coding, I used timers rather than RequestAnimationFrame to synchronize redraw). By just changing the arm_freq to 1350 this doubled, to a whopping 2 fps.

After i tweaked the memory clock-speed and gpu and set some overvoltage, that in turn went up to a stable 7 fps.

Since this is a per-pixel demo, meaning that it uses the canvas to draw stuff, with a secondary callback cycle applying an alpha clear to give the impression of fading pixels out ( fillrect(0,0,width,height, rgba(0,0,0,0.3)) ) running out of sync — the demo is actually processing millions of bytes per frame.

Just for sake of argument, lets say the chrome window is “1024 x 1024” in 32 bit mode (which is probably a bit small, but lets go with that). We then get:

  • 1024 * 4 (four bytes per 32 bit pixel) = 4096 bytes per scanline
  • 4096 * 1024 =¬†4,194304 million bytes per frame

There is also a stride offset, but I will ignore that since it probably amounts to about 1kb or less. Right, since we are now drawing 7 frames instead of 3, this gives us:

4 * 4194304 = 16,777216 Рa boost of 16.7 million bytes per second

20161117_214401

I may not be a Raspberry PI guru, nor would I pretend to be one, but boosting the javascript virtual machine by that magnitude is pretty good. And remember: JavaScript is single threaded. I have yet to see what happens when we use all the cores here.

But I am open for information and would love to hear your take on this. Im sure we can dig down and find out exactly which of my settings had the most impact.

Either way: overclocking and tuning the Raspberry PI 3 for better performance is possible. And that was the only thing on the table here.