error while loading shared libraries: libtorrent.so.19

After compiling rtorrent on Ubuntu 16.04 I got the following error message:
rtorrent: error while loading shared libraries: libtorrent.so.19: cannot open shared object file: No such file or directory

The solution was to add the following to /etc/ld.so.conf
include /usr/local/lib

Then after doing that run
ldconfig

Source: Ubuntu Forums

Raspbian upgrade from wheezy to Jessie hangs on Started Permit User Sessions.

After I upgraded from wheezy to jessie my Raspberry refused to boot. It was stuck on Started Permit User Sessions.
The solution is in editing the cmdline.txt at /boot

I changed mine from this:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:10 fbcon=font:VGA8x8 plymouth.enable=0

to this:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootdelay=10 rootwait usbhid.mousepoll=0 init=/lib/sysvinit/init

After reading at the Raspberry forums and it booted fine again.

Hårdvaruarkitektur i Raspberry Pi 1

På många hemsidor kan man läsa om att Raspberry Pi har en teoretisk busshastighet på 60MB/s. Detta är en väldigt grov förenkling som är baserad på att Raspberry Pi har en USB 2.0-kanal, denna är på 480mbit = 60MB/s.

Tittar man i dokumentationen står det så här;
The bus interface provides high bandwidth connections between the processor, second level caches, on-chip RAM, peripherals, and interfaces to external memory.

There are separate bus interfaces for:
*instruction fetch, 64-bit data
*data read/write, 64-bit data
*peripheral access, 32-bit data
*DMA, 64-bit data.

Bus clock speeds
The bus interface ports operate synchronously to the CPU clock if IEM is not implemented.

Huruvida IEM är implementerat på Raspberry Pi vågar jag inte svara på, men jag gissar på att det inte är det. Man har velat hålla priset så lågt som möjligt och det finns många rapporter på att de som överklockat sin Pi fått datakorruption.

Utgår man från att IEM är av, kan man dra följande slutsats;

Bussen mot ram är
5600MB/s = 700MHz * 64 bitar / 8 bitar

Bussen mot peripheral är
2800MB/s = 700MHz * 64 bitar / 8 bitar

De peripherals som Raspberryn har är GPIO-portar, SD-kortsläsare, USB och nätverk.

pi@raspberrypi ~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M
|__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M

Här kan vi se att det finns en intern USB-port i Raspberryn, denna delas sedan med ett kombinerat USB-hubb och nätverkschipp. Nätverkschippet sitter alltså anslutet på en USB-hubb som i sin tur sitter ansluten i den enda USB-porten. Detta förklarar varför den billiga Raspberry-modellen utan nätverk bara har en USB-port.

Den totala USB-bandbredden är 480mbit, vilket ger 60MB i teorin. I praktiken är teoretisk USB-throughput runt 53MB/s, men implementationerna är oftast så mycket sämre att man inte ska förvänta sig mer än runt ~30MB/s. Läs mer om detta här: http://electronics.stackexchange.com/questions/24700/why-are-usb-devices-slower-than-480-mbit-s


Raspberryn har ett minneschip anslutet. Detta är LPDDR2 från antingen Hynix eller Samsung och kör som standard 400MHz.
Båda modellerna av minnen är specade till 400MHz och 32bitar

3200MB/s = 800MHz * 32 bitar / 8 bitar

Detta resultat kan även verifieras mot följande benchmark:
https://panthema.net/2013/pmbw/RaspberryPi-ModelB/
Här är den sekventiella topprestandan som går att få ut ~1.17GB/s.
Tittar man på memset i tinymembench får man liknande siffror.

Dessa siffror tyder på en väldigt låg effektivitet på runt 35%.



Hynix: H9TKNNN4GDMP LRNDM 800MHz (400MHz)
http://www.hynix.com/inc/pdfDownload.jsp?path=/datasheet/Databook/Databook_MobileMemory.pdf

Samsung: K4P4G324EB-AGC1
http://www.samsung.com/global/business/semiconductor/html/common/file/support/part_number_decoder/Mobile_SDR_DDR_code.pdf

https://panthema.net/2013/pmbw/RaspberryPi-ModelB/
http://www.memetic.org/raspberry-pi-overclocking/
http://elinux.org/RPiconfig#Overclocking_options
http://www.petervis.com/Raspberry_PI/Raspberry_Pi_Model_B_512MB_RAM_Revision_2/K4P4G324EB.html


http://www.irongeek.com/i.php?page=security/svartkast-pogoplug-dropbox


Jag jämför tre system, ett Core 2 Duo med dualchannel, ett Atomsystem med single channel, samt en överklockad Raspberry.

Tittar vi på tiny membench sedan ser vi att skillnaden är långt mycket större än så.
Oftast har Raspberry Pi runt en tiondel av C2D-maskinen kan få ut.

För memset kan man se att Raspberryn når upp en effektivitet på ~18% medan C2D-systemet når runt ~40% och Atomsystemet drygt 55%.

C2D - DDR2 667MHz, 128bit - 10.6GB/s
C copy backwards : 1420.2 MB/s (1.3%)
C copy : 1413.9 MB/s (0.9%)
C copy prefetched (32 bytes step) : 1425.8 MB/s (1.0%)
C copy prefetched (64 bytes step) : 1432.0 MB/s (1.5%)
C 2-pass copy : 1309.2 MB/s (3.4%)
C 2-pass copy prefetched (32 bytes step) : 1359.3 MB/s
C 2-pass copy prefetched (64 bytes step) : 1365.6 MB/s (1.9%)
C fill : 1932.5 MB/s (2.2%)
---
standard memcpy : 2067.2 MB/s (1.0%)
standard memset : 4125.7 MB/s (0.5%)

RPi DDR2 1000MHz, 32bit, - 4GB/s
C copy backwards : 92.4 MB/s (7.1%)
C copy : 131.7 MB/s (6.4%)
C copy prefetched (32 bytes step) : 187.3 MB/s (10.2%)
C copy prefetched (64 bytes step) : 188.4 MB/s (1.4%)
C 2-pass copy : 115.0 MB/s (13.6%)
C 2-pass copy prefetched (32 bytes step) : 133.7 MB/s (8.8%)
C 2-pass copy prefetched (64 bytes step) : 146.3 MB/s (8.6%)
C fill : 450.3 MB/s (1.5%)
---
standard memcpy : 205.0 MB/s (3.0%)
standard memset : 721.3 MB/s (1.8%)

Atom N450 DDR2 667MHz, 64bit - 5.3GB/s
C copy backwards : 1186.6 MB/s
C copy : 1183.7 MB/s
C copy prefetched (32 bytes step) : 1015.0 MB/s
C copy prefetched (64 bytes step) : 1014.8 MB/s
C 2-pass copy : 1203.6 MB/s
C 2-pass copy prefetched (32 bytes step) : 898.5 MB/s
C 2-pass copy prefetched (64 bytes step) : 898.4 MB/s
C fill : 1520.9 MB/s (0.2%)
---
standard memcpy : 1670.0 MB/s (0.3%)
standard memset : 3028.3 MB/s



http://code.google.com/p/flashfire/

Kompileringsflaggor till Raspberry Pi

Jag försöker lista ut vilka GCC-flaggor man bör köra mot Raspberry Pi och vad som kan förbättra prestandan. Många är av åsikten att man inte köper en Raspberry för att få prestanda och att optimeringar därför är överflödigt. Personligen anser jag att ju simplare ett system är, desto mer finns det att hämta ur optimeringar. Dessutom kan man dra nytta av att systemet är slutet genom att det går att reproducera alla resultat.

I GCC finns det ett antal flaggor som jag valt att ta en titt på.
-pipe
-march
-mcpu
-mtune
-mfloat-abi
-mfpu
-O0
-O1
-O2
-O3
-Ofast
-Os

-fsched2-use-superblocks
-fira-hoist-pressure <- kan ge mindre kod, används i Os
-fira-loop-pressure <- används kanske vid O3
-fira-region= one för O1 Os, mixed för O2/O3, all ska prövas
-funsafe-loop-optimizations
-fmodulo-sched
-fmodulo-sched-allow-regmoves
-fgcse-sm
-fgcse-las
-fgcse-after-reload
-fmerge-all-constants

-fprofile-use path <- gör funroll loops och liknande! Path är inte obligatorisk


-pipe
Denna flaggan påverkar inte slutresultatet utan gör endast att GCC jobbar med pipes istället för temporära filer. Resultatet är att man får mindre diskaccess men betalar med ram.
Så länge GCC inte kraschar av brist på ram är -pipe att föredra, då det snabbar upp kompileringen. Särskilt på Raspberryn som har ett långsamt filsystem.

-march
Sätter vilken arkitektur GCC kompilerar för, detta avgör vilka assemblerinstruktioner som är tillåtna i slutbinären.
Exempelvis kan man kompilera för armv6, armv6j eller armv6zk. armv6j står för Jazelle, hårdvara för java. Enligt ARMs hemsida ger ARM1176JZF-S stöd för armv6k-extensions som inte ARM1176JF-S har. Läser man en mailinglista från GCC-utvecklare ska inget skilja mellan armv6zk och tidigare modeller från en kompilators perspektiv. Så armv6 borde ge precis samma prestanda som armv6j eller armv6zk.

-mcpu
Specificerar ännu striktare än -march, inte bara arkitektur utan även en specifik CPU. På detta sätt kan GCC optimera efter just den processorn man använder.
Processorn som sitter i Raspberry Pi heter ARM1176JZF-S, där F står för floating point. I GCC specificeras följande modeller inom Arm11:
‘arm1136j-s’, ‘arm1136jf-s’, ‘mpcore’, ‘mpcorenovfp’, ‘arm1156t2-s’, ‘arm1156t2f-s’, ‘arm1176jz-s’, ‘arm1176jzf-s’, den sista är den som sitter i Raspberry Pi

-mtune
Denna flagga optimerar efter en viss processor utan att begränsa instruktionsrymden till endast den processorn.
Exempelvis skulle man kunna köra -march i386 med mtune för Pentium 3 och på så sätt göra koden körbar på alla processorer som stöder i386, men optimera för Pentium 3.

-mfpu
Specificerar vilken FPU som finns tillgänglig. För Raspberry Pi finns endast vfp som alternativ.

-mfloat-abi
Ställer hur flyttalsoperationer ska utföras. Ska stå på hard för att Raspberryns VFP ska utnyttjas.

-O0
Optimering avslaget, detta är default

-O1
Lägsta nivån av optimering. Många optimeringar som ökar hastigheten utan att öka storleken, samt storleksreducerande optimeringar är aktiverade.

-Os
Tar alla storleksreducerande optimeringar från O2 plus några extra. Slutmålet är minsta möjliga binär

-O2
Som O1, fast mer av det goda. O2 tar längre tid att kompilera än O1.

-O3
Tillåter även kompileringar som ger större binärer. Risken med O3 är att den större och snabbare binären kan gå långsammare på grund av att mindre får plats i cache.

-Ofast
Som O3, fast med ytterligare ett par optimeringar (bland annat -ffast-math, Fortran-specific, -fno-protect-parens och -fstack-arrays). Är inte längre ISO/IEEE-kompatibel.

Källor:
http://www.arm.com/products/processors/classic/arm11/arm1176.php
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/apbs02s02.html
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
http://en.wikipedia.org/wiki/ARM11
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg03073.html

Benchmarks:
https://github.com/ssvb/tinymembench/wiki/Raspberry-Pi-%28BCM2708%29
http://www.netlib.org/benchmark/linpackc
http://www.openssl.org/source/

Running docker images on Raspberry Pi

My Raspberry Pi 2 is running Ubuntu. I wanted to try the phoronix test suite with a different compiler and thought that Docker could be great for this. After installing docker and trying to run my image I was met by "write pipe: bad file descriptor".

The issue was that docker is not architecture aware. Thus running "docker create ubuntu" will default to x86_64, regardless of your arch. To run ubuntu the solution was to ask for armv7/armhf-ubuntu instead.

Sources:
hub.docker.com - armv7
Stackoverflow

Set CPU Frequency on Raspberry Pi in FreeBSD

While benchmarking I noticed very low results with FreeBSD. Apparently the Raspberry Pi 2 is locked to the low frequency of 600MHz, while in Ubuntu a governor scales it between 600 and 900.
My first try was to edit /boot/msdos/CONFIG.TXT but the different overclocking values applicable for Linux did not affect FreeBSD.

The solution was to enable powerd in FreeBSD.

Add the following to /etc/rc.conf
powerd_enable="YES"
powerd_flags="-a hadp"

That will enable powerd to utilize frequency scaling from 600MHz to 900MHz depending on load. hadp means hiadaptive mode and is a scaling leaning towards more performance.
You can read more via "man powerd" and also try out different modes live, by running for example:
powerd -v -a hadp

Sources:
vzaigrin
nobugware

Portsnap fetch fails in RaspBSD 12 on RPi3

First I couldn't run 'portsnap fetch' due to the system time being off.
Snapshot appears to have been created more than one day into the future!
(Is the system clock correct?)
Cowardly refusing to proceed any further.

Setting the time using the command 'ntpdate' fixed that issue, but got me a new instead:
Verifying snapshot integrity... Segmentation fault (core dumped)
snapshot corrupt.

This can be worked around by manually installing the ports tree.
wget http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz
tar xvf ports.tar.gz -C /usr/

Sources:
FreeBSD documentation - using ports
slug

Resizing the root partition in RaspBSD 12

I was trying to resize the root partition for RaspBSD 12 on a Raspberry Pi 3 and ran in some trouble, since growfs showed "operation not permitted".

Here was my solution to resizing:
gpart show
This showed that my disk was named mmcsd0 and that my root partition had the index "2".

gpart resize -i 2 -a 4k -s 20gb mmcsd0
Here I'm resizing the root partition, 2, to 20gb

gpart commit
save the changes

service growfs onestart
resize the file system

Sources:
FreeBSD.org documentation
DigitalOcean