sudo apt-get install ttf-mscorefonts-installersource: stackoverflow.com
lördag 4 november 2023
Ubuntu missing web fonts.
After upgrading from Ubuntu 23.04 to 23.10 fonts on the web started looking weird. The solution was to install the microsofts fonts.
tisdag 13 december 2022
Steam Deck missing stdio.h
I tried to compile an application for the steam deck when I ran into missing header files. Weirdly the correct packages seemed to be installed, so why was I missing headers?
A reddit post explained that Valve had deleted some files belonging to installed packages and the resolution was to reinstall them.
So I ran the following command and surely, my compile worked afterwards.
A reddit post explained that Valve had deleted some files belonging to installed packages and the resolution was to reinstall them.
So I ran the following command and surely, my compile worked afterwards.
sudo pacman -S glibc linux-api-headers
söndag 14 mars 2021
Get full path for a file.
Time for another oneliner. I often need to get the full path of a file.
This can be done using the following command:
readlink -f myfile
Via stackoverflow.com
This can be done using the following command:
readlink -f myfile
Via stackoverflow.com
onsdag 3 mars 2021
Text disappearing from context menus in Gnome
I'm having an issue where most text in Gnome disappears or gets corrupted. I'm yet to find the root cause.
In the meantime the best quickfix is to restart Gnome.
To do so, press alt + F2, type r and press enter.
Via linuxconfig.org
In the meantime the best quickfix is to restart Gnome.
To do so, press alt + F2, type r and press enter.
Via linuxconfig.org
lördag 27 februari 2021
måndag 15 februari 2021
Can't init device hci0: Connection timed out (110)
Bluetooth stopped working on my raspberry pi running raspbian. The first I tried was to reset the interface by running hciconfig hci0 down/up, but that gave me "Can't init device hci0: Connection timed out (110)".
I found that by removing the btusb module and then adding it back, I was able to get bluetooth working again. Next time bluetooth gives up, I will run this:
sudo hciconfig hci0 down
sudo rmmod btusb
sudo modprobe btusb
sudo hciconfig hci0 up
Via unix.stackexchange.com
I found that by removing the btusb module and then adding it back, I was able to get bluetooth working again. Next time bluetooth gives up, I will run this:
sudo hciconfig hci0 down
sudo rmmod btusb
sudo modprobe btusb
sudo hciconfig hci0 up
Via unix.stackexchange.com
lördag 11 april 2020
Overclock works in Windows but hangs in Linux.
So I have this old Intel Lynnfield system from 2010. It's overclocked and has been so for many years. Works perfectly in Windows even during high load for several days. Ubuntu and other distributions I tried would randomly freeze. Even more strangely, it never happened during heavy load.
Maybe Linux uses some CPU instruction Windows doesn't and that particular instruction doesn't work with the overclock? I clocked the CPU down, but Linux would still hang randomly.
I upgraded the motherboard bios, I upgraded the GPU bios. I replaced the soundcard. I checked SMART data for the drives. I ran memtest. I tested with a different GPU vendor.
But I couldn't find what was going on. Why was it freezing, so randomly, when there was almost no load in the system?
But then, for some reason I checked the cpu frequency using /proc/cpuinfo. The CPU wasn't running at the speed I had specified in bios, it was clocking down. That could certainly explain why the system froze during low load scenarios. CPU scaling and overclocking seldom works well, but I had disabled the C-states in bios. I had disabled turbo in bios. I knew for a fact that this was the case, since I've checked it numerous times in Windows.
So I started searching about C-states and the Linux kernel. For some reason the kernel ignores whether the bios has turned off the c-states or not. Thus, my disabled C-states was enabled. Confusing and frustrating.
I tried to fix this by disabling cpu scaling within Ubuntu, but for some reason it never worked as it was supposed to. Then I found that there is a kernel parameter for specifying what level of C-state that is allowed.
intel_idle.max_cstate=1
So I opened up /etc/default/grub and modified the GRUB_CMDLINE_LINUX_DEFAULT:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"
Then I ran
sudo update-grub2
sudo reboot
Finally I confirmed that the cpu was no longer scaling using
cat /proc/cpuinfo
If I understand it correctly (haven't verified), you can set the max_cstate to 0 to disable the intel_idle driver, which should make the kernel use the bios/uefi settings instead.
Sources:
Info from Dell
Info from IBM
Maybe Linux uses some CPU instruction Windows doesn't and that particular instruction doesn't work with the overclock? I clocked the CPU down, but Linux would still hang randomly.
I upgraded the motherboard bios, I upgraded the GPU bios. I replaced the soundcard. I checked SMART data for the drives. I ran memtest. I tested with a different GPU vendor.
But I couldn't find what was going on. Why was it freezing, so randomly, when there was almost no load in the system?
But then, for some reason I checked the cpu frequency using /proc/cpuinfo. The CPU wasn't running at the speed I had specified in bios, it was clocking down. That could certainly explain why the system froze during low load scenarios. CPU scaling and overclocking seldom works well, but I had disabled the C-states in bios. I had disabled turbo in bios. I knew for a fact that this was the case, since I've checked it numerous times in Windows.
So I started searching about C-states and the Linux kernel. For some reason the kernel ignores whether the bios has turned off the c-states or not. Thus, my disabled C-states was enabled. Confusing and frustrating.
I tried to fix this by disabling cpu scaling within Ubuntu, but for some reason it never worked as it was supposed to. Then I found that there is a kernel parameter for specifying what level of C-state that is allowed.
intel_idle.max_cstate=1
So I opened up /etc/default/grub and modified the GRUB_CMDLINE_LINUX_DEFAULT:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"
Then I ran
sudo update-grub2
sudo reboot
Finally I confirmed that the cpu was no longer scaling using
cat /proc/cpuinfo
If I understand it correctly (haven't verified), you can set the max_cstate to 0 to disable the intel_idle driver, which should make the kernel use the bios/uefi settings instead.
Sources:
Info from Dell
Info from IBM
onsdag 11 mars 2020
Where does files mount in Ubuntu?
So I was mounting network directories using the graphical interface in the files application, when I needed to use the mount points with the terminal. Where are those mount points located?
That location is here:
/run/user/[uid]/gvfs/[mount]/
Source: askubuntu.com
That location is here:
/run/user/[uid]/gvfs/[mount]/
Source: askubuntu.com
torsdag 12 december 2019
openssl: Can't load /home/[username]/.rnd into RNG
On Ubuntu 18.04 LTS I got the following error message:
Can't load /home/sniglom/.rnd into RNG
The solution was to comment out the following line in /etc/ssl/openssl.cnf:
RANDFILE = $ENV::HOME/.rnd
I found this solution via the openssl project at github.
Can't load /home/sniglom/.rnd into RNG
The solution was to comment out the following line in /etc/ssl/openssl.cnf:
RANDFILE = $ENV::HOME/.rnd
I found this solution via the openssl project at github.
måndag 4 november 2019
Slack open links in its own browser on Ubuntu
Running 18.04 LTS I discovered an odd behavior from Slack. Instead of opening links in my regular FIrefox installation, it opened its own Firefox-instance. That instance had no plugins and was grouped as a slack process in the menu bar. Weird.
Reinstalling Slack from Ubuntu Software didn't help and I couldn't find a setting within Slack that controlled this.
The solution to my issue was to install the .deb file from Slack's homepage, instead of using Ubuntu Software. After doing so, links opened through my regular Firefox installation, instead of starting new processes belonging to Slack.
Source: askubuntu.com
Reinstalling Slack from Ubuntu Software didn't help and I couldn't find a setting within Slack that controlled this.
The solution to my issue was to install the .deb file from Slack's homepage, instead of using Ubuntu Software. After doing so, links opened through my regular Firefox installation, instead of starting new processes belonging to Slack.
Source: askubuntu.com
tisdag 1 oktober 2019
option OSS requires SDL_AUDIO
Trying to compile SDL20 I got the following message. It took a while before I realized that this wasn't a library that I needed to install, I needed to reconfigure SDL20 to add the SDL_AUDIO option.
To do that I simply ran "make config" in the SDL20 port directory and added SDL_AUDIO.
To do that I simply ran "make config" in the SDL20 port directory and added SDL_AUDIO.
FreeBSD: X needs Python 3.5 at least, but 2.7 was specified.
When trying to compile using the ports system, the error message that something needs Python 3.x, but 2.7 was specified is quite common.
This is due to the ports system "remembering" the python version that was specified by a top level package, while a dependency may require something else.
The solution is to manually compile the dependency first.
In my case I was trying to build sdl_sound, but it failed due to meson-0.51.2 needs Python 3.5 at least, but 2.7 was specified.
To fix this I compile meson first, then I go back and compile sdl_sound.
This is due to the ports system "remembering" the python version that was specified by a top level package, while a dependency may require something else.
The solution is to manually compile the dependency first.
In my case I was trying to build sdl_sound, but it failed due to meson-0.51.2 needs Python 3.5 at least, but 2.7 was specified.
To fix this I compile meson first, then I go back and compile sdl_sound.
söndag 22 september 2019
Avoid configuration prompts when installing freebsd ports
When installing ports with many dependencies, repeatedly stopping the compilation to show a configuration prompt is annoying, especially if you want the default values. This can be avoided in a couple of ways.
When installing a port, adding either of these batch flag uses default.
The batch flag can also be set as an environment variable.
What if you want to configure everything first and then compile?
Sources:
1 unix.stackexchange.com
2 unix.stackexchange.com
When installing a port, adding either of these batch flag uses default.
make install BATCH=YES
make install -DBATCH
The batch flag can also be set as an environment variable.
export BATCH=yes
What if you want to configure everything first and then compile?
make config-recursiveRemember that this command needs to be run many times until all configuration has been performed.
Sources:
1 unix.stackexchange.com
2 unix.stackexchange.com
Get octal permissions for files.
Sometimes it would be nice to read the permissions in octal, not only set it in octal.
This can be done using the stat tool.
This command will list all files/folders and their octal permission.
-c is for specifying the display format.
%a is the octal permission and %n is the file name.
Source: AskUbuntu.com
This can be done using the stat tool.
This command will list all files/folders and their octal permission.
stat -c "%a %n" *
-c is for specifying the display format.
%a is the octal permission and %n is the file name.
Source: AskUbuntu.com
söndag 11 december 2016
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
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
fredag 18 november 2016
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.
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.
måndag 14 november 2016
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.
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/
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/
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
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
onsdag 9 november 2016
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
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
Prenumerera på:
Inlägg (Atom)