Hardware: Raspberry Pi
Just few notes about Raspberry Pi ...
Contents
Power
According to details from RPi project voltage between 4.75 and 5.25 volts is fine. I personally preffer voltage between 4.80 and 5.00 volts. Voltage below 4.8 volts, can lead to instability of 3v3 regulator (RG2) (e.g. SoC power source) and connected equipment. Voltage above 5.00 (5.25) can shorten life of board and lead to problems with connected equipment. Voltage above 5.6V trip D17 over voltage protection diode. Make sure that connected USB hub (if any) is not back feeding power. It can cause serious problems as there is no protection on USB output ports.
If you are experiencing random USB device disconnects, repeating keys from keyboard or random reboots (hung) of board then there is something wrong with power source. I think USB charger as source was not so good decision as most of the chargers don't maintain stable voltage under load. This can lead to under voltage and cause stability problems. If you hit some of them, then try to measure voltage between test points or change power source.
My Raspberry Pi is running pretty stable with following power sources:
- RASPBERRY PI PSU is only 1A PSU, so no "hungry" devices. I Have ADATA N005 64GB USB flash disk + receiver for air mouse connected and it is just fine.
- STONTRONICS T5582DV Recomended for RPi2 and installation which require more current (e.g. many peripherals connected).
Boot configuration
Raspberry Pi don't have so called "BIOS" and it's configuration interface. Configuration of SoC is stored in /boot/config.txt. If you have problem with overscan or screen resolution then You can resolve it by modification of this file. For example I have one RPi connected to old television and this television don't use overscan only if output of RPi is in DMT / PC mode. My boot config for this RPi running Raspbmc is:
# default Raspbmc config arm_freq=850 core_freq=375 force_turbo=1 gpu_mem_512=128 gpu_mem_256=112 disable_overscan=1 start_file=start_x.elf fixup_file=fixup_x.dat # My configuration: # Set stdv mode to PAL (as used in Europe) sdtv_mode=2 # Force the monitor to HDMI mode so that sound will be sent over HDMI cable hdmi_drive=2 # Set monitor mode to DMT hdmi_group=2 # Set monitor resolution to 1360x768 60Hz hdmi_mode=39 # EOF
Note1: Default configuration as of 2014-08-12.
Note2: I removed "hdmi_ignore_cec_init=1". According to elinux.org this option is: Doesn't sent initial active source message. Avoids bringing (CEC enabled) TV out of standby and channel switch when rebooting. This can cause problems to several types of TVs. I know at least one which is ignoring CEC if there was no "active source" message. Best way to prevent wakeup of TV is to configure TV itself. If this is not possible then configuration can be set via XBMC gui (system -> settings -> system -> input devices -> peripherals). Disabling CEC init at SoC level may lead to CEC malfunction at all.
More details can be found on elinux.org in section RPi_config.
Licensed and enabled codecs
To reduce cost Raspberry Pi is shipped without license to MPEG2 and VC-1. Raspberry Pi core is different from regular PC-AT system so there is special command to check status and details. Command vcgencmd provide a lot of details about Broatcom SoC used by Raspberry Pi. Following for cycle show details about all codecs:
for codec in H264 MPG2 WVC1 MPG4 MJPG WMV9 ; do \
echo -e "$codec:\t$(vcgencmd codec_enabled $codec)" ; \
done
This is output from RPi with no license installed. As expected MPEG2 and VC-1 is disabled:
H264: H264=enabled MPG2: MPG2=disabled WVC1: WVC1=disabled MPG4: MPG4=enabled MJPG: MJPG=enabled WMV9: WMV9=disabled
I bought both codecs from RPi Store and it cost me only 4,48 EUR (6.11.2013). Link to RPi store is here. I received license for both codecs in about 3.5 hour. Pretty fast :o) Installation is simple. Just edit /boot/config.txt and insert received license in following format:
decode_MPG2=0x00000000 decode_WVC1=0x00000000
Now RPi need reboot. After boot up it should have all codecs enabled:
H264: H264=enabled MPG2: MPG2=enabled WVC1: WVC1=enabled MPG4: MPG4=enabled MJPG: MJPG=enabled WMV9: WMV9=enabled
Temperature
I was trying to get clear answer "what is safe temperature" for Raspberry Pi and apparently there is no clear statement. From my findings safe temperature is up to 60C and shutdown temperature should be 70C. Although it looks like RPi can run up to 80C. Running close to this temperature can reduce board lifetime. Current temperature measured by SoC itself can be displayed by vcgencmd command or by direct read from /proc file system.
$ vcgencmd measure_temp temp=54.1'C
FYI 1: original plastic case with ventilation opening in RPi logo is concentrating heat. Test show that this case cause board to head-up by 10C.
FYI 2: small "ram" heat sink don't change temperature too much especially if adhesive side is cheaper with significant thermal resistance. I tried several heat sinks and result was only 2 to 5 degree Celsius temperature drop.
FYI 3: My recommendation for case: EM-RasPI B+ by EMKO Case
Additional software
List of handy tools in case of manual configuration or simple debugging:
apt-get install screen strace htop nload traceroute mc ddrescue rsync \
vim pydf ca-certificates lsscsi lsof collectl atop psmisc
FS cache
FS cache can store read only cache pages from NFS to speedup further reading of filesystem. I'll use it to reduce network load. Configuration is following:
My cache disk (usb key) is /dev/sda. First of all I created partition over whole disk.
Device Boot Start End Blocks Id System /dev/sda1 2048 123535359 61766656 83 Linux
Then file system:
mkfs.ext4 -m 0 -O dir_index -L fscache /dev/sda1 tune2fs -o user_xattr /dev/sda1
Reserve for root is not necessary (so 0%). If your cache is filling up to more that 95% then try to modify configuration or increase reserve. Using last 5% of free space can cause significant impact on response time. (Tested on 64GB filesystem).
Note: apparently journal on device is required by kernel driver. Without it registering of cache fail with strange error.
Cache coherency information is stored inside extra attributes on file system. Therefore it is necessary to mount it in following way (/etc/fstab):
# <fs> <mountpoint> <type> <opts> <dump/pass> LABEL=fscache /var/cache/fscache ext4 defaults,noatime,user_xattr 0 2
Note: I am not sure why but by default raspbmc is is skipping fsck during boot. Correction in fstab don't help as script for fsck is not invoked at all during boot-up.
Mount of file system itself:
mkdir -p /var/cache/fscache mount /var/cache/fscache
Now fs cache daemon installation:
apt-get install cachefilesd
By default is is disabled. To enable it use modify /etc/default/cachefilesd:
RUN=yes
Configuration of daemon should point to mounted file system (config file: /etc/cachefilesd.conf):
dir /var/cache/fscache tag mycache brun 10% bcull 7% bstop 3% frun 10% fcull 7% fstop 3%
If yes then it is time to start daemon:
/etc/init.d/cachefilesd start
Successful start is indicated by message:
[ ok ] Starting FilesCache daemon : cachefilesd.
and entry in kernel log:
FS-Cache: Cache "mycache" added (type cachefiles) CacheFiles: File cache on sda1 registered
Now NFS mounted with "fsc" option will store cached data also into "files" (v2/3 only RO pages). Preferably whole file system should be mounted as "ro".
Results
For test I selected remote NFS server (max 10Mbit/s, ~35 ms latency). Maximum throughput during first read was approximately 7.33 Mbit/s and average at 5.00 Mbit/s (measured by nload). Reading of ~700 MB file took 1108.6 seconds.
702+1 records in 702+1 records out 736593920 bytes (737 MB) copied, 1108.6 s, 664 kB/s
Second reading show significant improvement. First of all there was no noticeable network activity and reading of same file took only 33.04 seconds.
702+1 records in 702+1 records out 736593920 bytes (737 MB) copied, 33.0383 s, 22.3 MB/s
Note: speed approximately at 22.3 MB/s is limitation of Raspberry Pi USB2 controler.
NFS vs. CIFS
There are two possibilities how to mount remote file system. NFS or SMB/CIFS. If i compare both protocols then i can say: if possible then use NFS. SMB/CIFS is working also, but this protocol require more CPU, access is less "Unix like" and under same condition CIFS use more bandwidth in both directions. Usable throughput is lower compared to NFS. On regular system this is normally not noticeable, but RPi have limited resources. Therefore use NFS, if it is possible and don't expect too much if you are using CIFS.
I am using following NFS mount options:
ro,fg,hard,tcp,vers=3,ac,nolock,fsc
-
ro- media PC is "consumer" of data so read only is enough. This also ensure that all cache pages are marked as R/O therefore cached locally by FS-Cache -
fg- foreground mount is by default. In case of problem sooner or later mount command fail on timeout. I prefer visible error message during boot-up in case of problem. -
hard- most of the applications don't react correctly on errors from VFS. It is safer to let NFS client retry till NFS server respond. Anyway media PC can't work without connection to "source" of data. -
vers=3- NFS protocol version. Version 3 is still preferred but if server support version 4 then you can try if it works better (I don't recommend version 2) -
ac- cache file attributes on client. It is not expected that source for media PC change too quickly so it is safe to cache attributes locally -
nolock- don't use remote locking. Lock daemon is not necessary in this configuration and locking files on RO mount don't make sense. -
fsc- enable the FS-Cache
NFS client try to negotiate maximum read/write size during mount of file system. It should select optimal value automatically. Result of negotiation is not visible via mount as this command read /etc/mtab file. To see real value it is necessary to check /proc/mounts which contain in kernel data. If negotiated size is not at least 32K then try to raise this value with following additional mount options (and also check server configuration):
rsize=32768,wsize=32768
Note: media PC read data sequentially. Therefore higher value can be better (64K, 128K ... NFS Client on Linux support size up to 1M)
NTP
All my devices are synchronized agains my Stratum 2 NTP server. This server will be Stratum 1 NTP server soon. With this change I make it also available for public use. For now I share only configuration of client (/etc/ntp.conf):
# Name of the servers ntpd should sync with # <server hostname> (local clock hub) server <server IP> # local failback in case of network failure server 127.127.1.0 # you should not need to modify the following paths driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp.log # restriction config restrict default nomodify notrap nopeer # EOF
Note: you should select and put IP of NTP server(servers) in this configuration.
Uptime contest
If you whould like to "log" maximum uptime of your RPi then there is good program. It is called uptimed. Installation is simple:
apt-get install uptimed
Usage also (installed recently):
pi@raspbmc:~$ uprecords
# Uptime | System Boot up
----------------------------+---------------------------------------------------
1 0 days, 00:28:16 | Linux 3.10.17 Tue Nov 12 09:24:06 2013
-> 2 0 days, 00:02:20 | Linux 3.10.17 Tue Nov 12 09:52:31 2013
3 0 days, 00:01:21 | Linux 3.10.17 Tue Nov 12 09:52:10 2013
----------------------------+---------------------------------------------------
no1 in 0 days, 00:25:57 | at Tue Nov 12 10:20:47 2013
up 0 days, 00:31:57 | since Tue Nov 12 09:24:06 2013
down 0 days, 00:-01:-12 | since Tue Nov 12 09:24:06 2013
%up 103.902 | since Tue Nov 12 09:24:06 2013
pi@raspbmc:~$
Note: looks like there is still bug in this package. If NTP change time/date significantly (during boot or if synchronization is not stable) then this software detect it as new boot entry. This may lead to duplicate entries shortly after boot or several entries covering one uptime. If you notice this behavior then check your time synchronization and/or internet connection.
SD Card speed
Raspberry Pi use connection which allow only "Class 10" connection to SD Card. This is limiting maximum throughput to SD Card and is source of differed kind of discussion. Which card is better for Raspberry Pi ? I saw responses "Class 4", also "Class 10 is enought" and then "UHS-I Ultimate".
I did test in past but unfortunately I don't preserve test output details :( So no numbers but at least details:
- Class 4 -> Throughput limited by card to 4MB/s. Random operations show poor results mostly likely due to throughput limitation.
- Class 10 -> Throughput limited by card to 10MB/s. Random operations show average results. With size of IO it was getting better.
- UHS-I Ultimate -> Throughput limited by RPi. Random operations show good result regardles of size of IO. I think this may be due to internal "IO capacity" of SD Card.
Note 1: Above test is specific to first version of Raspberry Pi. RPi2 don't have such a limitation on SD Card connection (I see 65MB/s of write and 154MB/s of read on my RPi2 with UHS-I Ultimate SD Card).
Note 2: I use only Kingston SD Cards.
Troubleshooting
Network
- Problem: dmesg contain a lot of smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped and/or allocation failures.
- Solution: If you are not running latest firmware then update firmware first. If message remain then try to disable turbo mode by adding smsc95xx.turbo_mode=N to
/boot/cmdline.txt. Additionally you may try to change vm.min_free_kbytes to 4096 or up to 16384 (/etc/sysctl.conf).
