Raspberry Pi's standard Raspbian OS configuration by default has an extensive set of logging options enabled for rsyslog, and the file system is configured in ordered data mode. While such a configuration might be understandable from the viewpoint of system stability and error reporting, it is not beneficial for performance to the say the least, causing a flash write access bottleneck for overall system performance.
Reducing logging activity, using tmpfs and using ramdisk for cache directories
The Raspberry Pi's rsyslog configuration files are stored in /etc/rsyslog.conf. Comment out the many logging rules by prefixing them with a '#' will eliminate logging activity.
The following lines added to /etc/fstab cause /tmp and /var/tmp to be stored in ramdisks:
To move cache directories to ramdisk, create the file /etc/profile.d/xdg_cache_home.sh with the following content:
tmpfs /tmp tmpfs defaults 0 0 tmpfs /var/tmp tmpfs defaults 0 0
#!/bin/bash export XDG_CACHE_HOME="/dev/shm/.cache"
Optimizing the file system
The Raspberry Pi does not accept the journal_async_commit mount option. However, write-back mode can be enabled and barriers can be disabled. Note that the risk of file system corruption with these settings is greater for the Raspberry Pi than for battery-powered devices.
It is best to store the performance options as default mount options in the filesystem itself using tune2fs. Data write-back mode (as opposed to the default ordered data mode) and no barriers are configured with the following command, assuming the root file system is stored in the /dev/mmcblk0p2 partition as it is on Raspbian:
When an error is detected during mounting at boot (including an option that is not accepted), the root file system will be mounted read-only, so that configuration files cannot be changed. It is however possible to remount the filesystem in read-write mode using the following command:
sudo tune2fs -o journal_data_writeback,nobarrier /dev/mmcblk0p2
sudo mount -o remount,rw /dev/mmcblk0p2 /
Disabling X windows system error logging
Edit the file /etc/X11/Xsession and edit the relevant lines to look like this (somewhere in the middle of the file), The log-generating line is commented out and replaced with a one that routes messages to /dev/null:
#exec >> "$ERRFILE" 2>&1 exec >> /dev/null 2>&1
Increasing the size of the console font
The Raspberry Pi comes configured with a relatively small font in the text console. However, it is easy to configure a larger font that greatly improves readability by editing /etc/default/console-setup to include, for example, the following two lines:
This configures a highly readable 16x32 font. This amounts to 80x32 characters on a 1280x1024 monitor. On a 1920x1024 monitor, this amount to 120x33 characters with 24 scanlines unused.
Editing nano context highlighting configuration
The convenient nano text editor comes configured with context-sensitive color highlighting by default. It operates using rules read from a configuration file, which depends on the file extension of the file being edited. Some of these rules are very complex and much too slow for a device such as the Raspberry Pi, resulting in sluggish editing. For example, the rules for C/C++ source files in /usr/share/nano/c.nanorc includes a rule labelled with the comment "This string is VERY resource intensive!". Commenting out this rule by putting a '#' in front of it results in greatly improved experience editing C/C++ source files. Similar resource intensive rules exist in the configuration for assembler files in /usr/share/nano/asm.nanorc.
Overclocking options can be set using raspi-config configuration utility. Overclocking is often stable on the device. I had no problems with the highest "Turbo" setting, which overclocks the CPU to 1000 MHz and the RAM to 600 MHz. The "core frequency" is also doubled from 250 MHz to 500 MHz. This frequency is tied to the L2 cache used by the GPU (it does appear to cause large increase in GPU performance).
On the Raspberry Pi 2, the default clock speed is 900 MHz, while the "core frequency" (which has a different meaning than it has for original Raspberry Pi) is a conservative 250 MHz. The main overclocking option intended for the Raspberry Pi 2 clocks the CPU cores at 1000 MHz, RAM at 500 MHz, and doubles the "core frequency" to 500 MHz. This has a positive effect on performance (especially memory performance), suggesting that the core clock is indeed correlated with CPU cache speed on the Raspberry Pi 2, which has a seperate L2 cache for the CPU. However, this setting turned out to be not quite 100% stable, with the culprit being an SDRAM speed that is slightly too high.
The amount of memory allocated to the GPU (memory split) should be set to the something like 128 if you want to be able run a wider range of OpenGL ES 2.0 applications, assuming a 512 MB Raspberry Pi.
The performance increase from overclocking the CPU and RAM is measurable in low-level benchmarks. The following benchmarks were run with framebuffer_depth=32 in /boot/config.txt and a monitor resolution of 1280x1024.
Running the benchmark program from the "fastarm" repository (http://www.github.com/hglm/fastarm) as follows shows a significant performance increase from the default settings:
The memset benchmark (which reflects sequential DRAM write access) shows a performance increase from 1220 MB/s to 1929 MB/s (58%). The memcpy benchmark (which reflects copying a sequential memory region of 4 KB) shows an increase from 320 MB/s to 432 MB/s (35%). The third benchmark (which reflects smaller memory copies of varying size) is also dependent on CPU performance. It shows an impressive increase from 206 MB/s to 353 MB/s (71%).
./benchmark --memset a --test 4 ./benchmark --memcpy a --test 43 ./benchmark --memcpy a --test 0
On the Raspberry Pi 2, the memset benchmark only scores 1090 MB/s with default settings. This seems to be a bandwidth bottleneck related to CPU and L2 cache speed limitations since other memset variants (including one using NEON SIMD instructions) show the same result. Multi-threaded benchmarks may potentially show higher throughout. However, when using the overclocking option, which significantly increases the clock speed of the L2 CPU cache, memset performance increases to 1730 MB/s, in line with the Raspberry Pi.
The second benchmark (4K memcpy) reports 965 MB/s, which is significantly faster than the original Raspberry Pi. This seems to imply that write bandwidth provides the bottleneck. When overclocking, the result further increases to 1380 MB/s. The third benchmark (memcpy of regions of varying size) reports 673 MB/s, significantly higher than the original Raspberry Pi, which increases to 785 MB/s when overclocking.
The low-level benchx program (http://www.github.com/hglm/benchx) can be used to measure pixel performance in the X server. A command line similar to the one below was used:
Overclocking shows the following improvements (measurements in MBytes/s) on the Raspberry Pi:
./benchx --window All
The SRE real-time rendering library (http://www.github.com/hglm/sre) allows us to measure 3D GPU performance. The following benchmarks were run:
Test Standard Overclock (Turbo) Speed-up ScreenCopy (33x33) 84.7 150 77% ScreenCopy (549x549) 184 277 51% FillRect (33x33) 842 1282 52% FillRect (549x549) 1161 1835 58% PutImage (549x549) 45.1 72.8 74% ShmPutImage (549x549) 229 365 59% ShmPutImageFullWidth (109x109) 298 534 79% ShmPutImageFullWidth (549x549) 233 364 56%
The first benchmark, a complex 3D benchmark with multiple lights, multi-pass rendering and shadows, shows an increase from 1.118 fps to 1.325 fps (19%) when overclocking. The second benchmark only uses only a single light with single-pass rendering and no shadows and shows an impressive increase from 13.2 fps to 27.2 fps (106%). The third benchmark, a lighter benchmark which uses a lot of alpha blending, increased from 30.2 fps to 48.0 fps (59%).
./sre-demo --benchmark --multi-pass --multiple-lights --shadow-volumes demo2 ./sre-demo --benchmark demo2 ./sre-demo --benchmark demo9
On the Raspberry Pi 2, the first benchmark reports an even slower framerate of 0.91 fps, while the second benchmark scores 20.5 fps, and the third benchmark scores 32.5 fps. Surprisingly, these results do remain about the same when overclocking. This is probably because on the Raspberry Pi 2, the core_freq setting does not directly affect the GPU.
File system benchmarks
Testing low-level file system performance using flash-bench (http://github.com/hglm/flash-bench) gives an indication of flash storage performance. A high-speed UHS 1 MicroSD card was used (using an SD card adapter). Measurements in MB/s.
The results show very slow random write performance, despite the use of the journal_data_writeback and nobarrier options, when compared to testing on other devices. Whether this is reflected in actual real-world performance is unclear.
Seq. Seq. Random Random Read Write Read Write PC (using USB SD card adapter) 18.1 15.7 3.55 15.3 Raspberry Pi, optimized fs options 17.2 13.3 4.35 0.96 Raspberry Pi (turbo overclock) 17.2 14.4 4.83 0.86 Raspberry Pi 2 17.4 14.5 5.09 1.47 Raspberry Pi 2 (same card via USB) 16.2 10.9 4.38 1.19 Raspberry Pi 2 (different card) 17.7 9.5 4.46 1.31 Raspberry Pi 2 (same card, overclock) 17.7 9.7 4.52 1.56 Raspberry Pi 2 eMMC via USB 17.8 14.4 4.38 6.80
The last entry is for a high-performance eMMC flash module fitted on an eMMC-to-MicroSD adapter fitted on a USB Micro-SD reader. This shows that higher random write performance is possible given high performance flash memory. Although I have not tested this set-up with the Raspberry Pi 2's internal MicroSD card slot, it would probably deliver similar or better performance.
Updated February 25, 2015.