Here are some first impressions of my new ODROID-XU4 CloudShell-2 with a custom blue LED FAN. Some more posts coming soon.
Tag: Odroid
Upgrade ODROID-XU4 to OpenMediaVault 3
This short tutorial will show you how to upgrade a ODROID-XU4 running OpenMediaVault 2 to OpenMediaVault 3.
OMV 3 (Erasmus) uses Debian 8 (Jessie) instead of 7 (Wheezy). So alongside OMV you will get new packages as well.
- Make a backup of your current installation!
- Make sure your system is up-to date by running: apt-get update && apt-get upgrade
- Reboot
- Uninstall all plugins including the OMV-Extras package
- Before you upgrade you should change your
boot.ini
and/etc/fstab
.
Mount your boot partition like this:mkdir /media/boot mount /dev/mmcblk0p1 /media/boot
- Then edit your
/media/boot/boot.ini
and change ro to rw in the setenv line. The line should look like below:setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=<YOUR_ROOTFS_UUID> rootwait rw fsck.repair=yes"
- Record your rootfs UUID
- Afterwards edit your
/etc/fstab
and add the following above the openmediavault volumes:# UNCONFIGURED FSTAB FOR BASE SYSTEM UUID=<YOUR_ROOTFS_UUID> / ext4 errors=remount-ro,noatime,nodiratime 0 1 # >>> [openmediavault] [...]
- Finally run omv-release-upgrade and reboot afterwards
- Now you can install the OMV-Extras package for OMV 3 and your plugins again:
wget dpkg -i openmediavault-omvextrasorg_latest_all3.deb apt-get update
ODROID-XU4 tune network and USB speed
It’s time for another small blog about the ODROID-XU4.
This is just a quick tip to improve your network and USB performance even more. It will optimize your hardware interrupts (IRQ) affinity on your ODROID-XU4.
This guide is for the 3.10.y kernel and debian 8. For other kernel versions the interrupts may have different numbers.
Description
Whenever a piece of hardware, such as disk controller or ethernet card, needs attention from the CPU, it throws an interrupt. The interrupt tells the CPU that something has happened and that the CPU should drop what it’s doing to handle the event. In order to prevent multiple devices from sending the same interrupts, the IRQ system was established where each device in a computer system is assigned its own special IRQ so that its interrupts are unique.Starting with the 2.4 kernel, Linux has gained the ability to assign certain IRQs to specific processors (or groups of processors). This is known as SMP IRQ affinity, and it allows you control how your system will respond to various hardware events. It allows you to restrict or repartition the workload that you server must do so that it can more efficiently do it’s job.
Source
It’s always a good idea to spread your interrupts evenly across all CPUs. In my case I want to achieve the best performance possible. Therefore I want to use the faster A15 CPU cluster for all important interrupt handling.
There are basically 3 different interrupts on a headless ODROID-XU4 server you should take into consideration:
- the USB2 port
- the first USB3 port
- the second USB3 port (the 1 Gigabit ethernet adapter is connected to this one)
Per default all 3 interrupts for these devices are handled by CPU0, which is a A7 core as you can see in the output below:
lscpu -e CPU SOCKET CORE ONLINE MAXMHZ MINMHZ 0 0 0 yes 1400.0000 200.0000 1 0 1 yes 1400.0000 200.0000 2 0 2 yes 1400.0000 200.0000 3 0 3 yes 1400.0000 200.0000 4 1 4 yes 2000.0000 200.0000 5 1 5 yes 2000.0000 200.0000 6 1 6 yes 2000.0000 200.0000 7 1 7 yes 2000.0000 200.0000 grep -E 'CPU0|usb' /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 103: 1 0 0 0 0 0 0 0 GIC ehci_hcd:usb1, ohci_hcd:usb2 104: 12853 0 0 0 0 0 0 0 GIC xhci-hcd:usb3 105: 7489 0 0 0 0 0 0 0 GIC xhci-hcd:usb5
IRQ Tuning
First of all make sure that automatic IRQ balancing is disabled:
systemctl disable irqbalance
For debian add the following to your /etc/rc.local file to pin the interrupt handling to A15 cores 4-6 (CPU4-6):
# Move USB and network irqs to A15 CPU cluster # usb2 echo 6 > /proc/irq/103/smp_affinity_list # usb3 echo 5 > /proc/irq/104/smp_affinity_list # network (usb3) echo 4 > /proc/irq/105/smp_affinity_list
After a reboot and some file transfer you should see something like this:
grep -E 'CPU0|usb' /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 103: 1 0 0 0 0 0 0 0 GIC ehci_hcd:usb1, ohci_hcd:usb2 104: 8355 0 0 0 0 249689 0 0 GIC xhci-hcd:usb3 105: 436 0 0 0 4396187 0 0 0 GIC xhci-hcd:usb5
Note the numbers for CPU4 and CPU5. CPU0 handled some initial interrupts during the boot, because rc.local isn’t executed immediately.
Benchmarks
Tuning without measuring performance before and afterwards is useless. So, here are some iperf results:
# without irq tuning iperf -c 192.168.0.2 -i 2 -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.0.2, TCP port 5001 TCP window size: 272 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.0.121 port 57696 connected with 192.168.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0- 2.0 sec 198 MBytes 830 Mbits/sec [ 5] 2.0- 4.0 sec 198 MBytes 830 Mbits/sec [ 5] 4.0- 6.0 sec 201 MBytes 842 Mbits/sec [ 5] 6.0- 8.0 sec 199 MBytes 835 Mbits/sec [ 5] 8.0-10.0 sec 199 MBytes 835 Mbits/sec [ 5] 0.0-10.0 sec 995 MBytes 834 Mbits/sec [ 4] local 192.168.0.121 port 5001 connected with 192.168.0.2 port 41073 [ 4] 0.0- 2.0 sec 206 MBytes 865 Mbits/sec [ 4] 2.0- 4.0 sec 207 MBytes 870 Mbits/sec [ 4] 4.0- 6.0 sec 210 MBytes 881 Mbits/sec [ 4] 6.0- 8.0 sec 211 MBytes 883 Mbits/sec [ 4] 8.0-10.0 sec 210 MBytes 882 Mbits/sec [ 4] 0.0-10.0 sec 1.02 GBytes 876 Mbits/sec # with irq tuning iperf -c 192.168.0.2 -i 2 -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.0.2, TCP port 5001 TCP window size: 289 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.0.121 port 57702 connected with 192.168.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0- 2.0 sec 224 MBytes 941 Mbits/sec [ 5] 2.0- 4.0 sec 223 MBytes 936 Mbits/sec [ 5] 4.0- 6.0 sec 223 MBytes 935 Mbits/sec [ 5] 6.0- 8.0 sec 223 MBytes 937 Mbits/sec [ 5] 8.0-10.0 sec 223 MBytes 934 Mbits/sec [ 5] 0.0-10.0 sec 1.09 GBytes 936 Mbits/sec [ 4] local 192.168.0.121 port 5001 connected with 192.168.0.2 port 41076 [ 4] 0.0- 2.0 sec 219 MBytes 920 Mbits/sec [ 4] 2.0- 4.0 sec 220 MBytes 924 Mbits/sec [ 4] 4.0- 6.0 sec 220 MBytes 924 Mbits/sec [ 4] 6.0- 8.0 sec 220 MBytes 924 Mbits/sec [ 4] 8.0-10.0 sec 220 MBytes 924 Mbits/sec [ 4] 0.0-10.0 sec 1.08 GBytes 923 Mbits/sec
Up to 100 Mbit/s faster. Not bad for such an easy fix 🙂
Read my post in the ODROID forum to get some more information and tuning tips.
Lower GPU clock of ODROID-XU4 for headless servers to save energy
Per default the Mali-T628 GPU inside the ODROID-XU4 will run at maximum speed (600MHz) the whole time.
This doesn’t consume that much energy if there is no load on the GPU. But nevertheless you can tune this a little bit if you don’t need the GPU at all.
Your kernel needs the following commit: mali: restore sysfs entries
Newer 3.10 ODROID-XU4 kernels should have this activated. I tested this with my own custom build kernel. You can grab it here. Source.
To flash this kernel you can use a script like this one.
To lock the GPU frequency to the lowest frequency possible (177MHz) do the following. This will automatically lower the voltage as well (see cat /sys/devices/11800000.mali/vol before and after the change).
apt-get install sysfsutils vi /etc/sysfs.conf --- # lower mali gpu clock to min (Kernel 3.10) devices/11800000.mali/dvfs_max_lock = 177 # UPDATE: for Kernel 4.9 do the following devices/platform/11800000.mali\:/devfreq/11800000.mali\:/governor = powersave # UPDATE2: for Kernel 4.14 do the following devices/platform/11800000.mali/devfreq/devfreq0/governor = powersave --- service sysfsutils start
The SOC will be 1-3°C cooler as well 🙂 Perfect for headless servers.
ODROID-XU4 with OpenMediaVault
Preface
Nearly 3 years ago I have bought myself a PogoplugV2 (see Post). It is still an awesome device for this price and worked without any issue the whole time.
However it is time for an upgrade. USB 2.0 was a little bit too slow for me (~30MB/s). In addition I have a lot of external USB 3.0 HDDs and it is time to use their full potential. So there are 4 key points a device needs to become my next NAS (Network-attached storage) and home server system:
- reasonable fast ARM processor with at least 2 cores (I prefer ARM over x86 for this use case because of its low energy consumption)
- Gigabit ethernet
- at least 2 USB 3.0 ports because I want to attach 2 active 4-port USB hubs. Almost all USB hubs >4 ports are cascaded 4 port hubs. This is quite bad because it can cause a lot of compatibility and of course performance issues.
- all together <150€. I do not want to pay 300-400€ for a simple NAS with USB disks…
ODROID-XU4
After a bit of research I have bought an ODROID-XU4.
Let’s look at the specs:
- Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs
- Mali-T628 MP6(OpenGL ES 3.0/2.0/1.1 and OpenCL 1.1 Full profile)
- 2Gbyte LPDDR3 RAM PoP stacked
- eMMC5.0 HS400 Flash Storage
- 2 x USB 3.0 Host, 1 x USB 2.0 Host
- Gigabit Ethernet port
- HDMI 1.4a for display
- Size : 82 x 58 x 22 mm
- Price: ~80 € + PSU ~8 € + Case ~8€ = ~96 €
I do not need the GPU and display output but whatever… the price is quite good for this performance. It is less expensive in US than it is in germany. But that is always the case 😉
Additional equipment
I am using a microSD Card for OS because eMMC is quite expensive. Boot times and program loading times are not that important my use case.
With two additional 4 port active USB 3.0 hubs I have 8 USB 3.0 ports and 1 USB 2.0 port. At the moment 5 disks are connected with a total of 7.5 TB storage.
Connecting a 2 TB disk to each USB 3.0 port would be 16 TB storage which should be good enough for some time.
- SanDisk Extreme 32GB microSDHC UHS-I ~20 €
- 2x EasyAcc® Superspeed USB 3.0 4 Port Bus-Powered and Self-Powered 2-in-1 Hub 2x ~11 €
- Anker 20W Dual-Port USB Wall Charger to power USB Hubs ~10 €
OS Choices
The ODROID-XU4 SOC is the same as its predecessor ODROID-XU3. That is why they share a common kernel and os images are compatible.
Nevertheless Exynos5422 SOC is not fully integrated in mainline kernel yet. That is why you have to use a custom kernel from hardkernel. But that is not a big issue because there a quite a few OS choices with the custom kernel like Android (ofc pretty useless for NAS), Ubuntu 15.04, Arch Linux, Fedora, Kali Linux, …
Also I really like Arch Linux I have chosen a different path this time. There is OpenMediaVault (OMV) for some Odroids. I thought hey let’s give it a try the web interface looks quite nice.
After a few days I can say I really like it. The web interface is really good and looks modern.
OMV is running on Debian Wheezy 7.9.
Installation
Download OpenMediaVault Image from: http://sourceforge.net/projects/openmediavault/files/Odroid-XU3_XU4/
Extract the downloaded image
gunzip -d omv_2.1.1_xu3_xu4.img.gz
Search for the path of your microSD Card with lsblk or sudo fdisk -l
Write the image to your microSD card with the following commands:
sudo dd if=omv_2.1.1_xu3_xu4.img of=/dev/<Your_SD> bs=4096 sync
Insert your microSD card and power your Odroid.
Then you can login via SSH or web interface:
SSH
username: root
password: odroid
Web interface
username: admin
password: openmediavault
I will not go into detail on how to configure stuff in the web interface because that is really easy and straightforward. I will focus on optimizing performance and adding a few neat features.
Basic configuration
Connect to your Odroid via SSH with default login credentials (see above).
Afterwards change your root password with passwd
You should change your web interface password, too.
Colorful Shell
Because we will use the shell for quite some time let’s add some color to it:
vi ~/.bashrc and comment out the following lines:
# You may uncomment the following lines if you want `ls' to be colorized: export LS_OPTIONS='--color=auto' eval "`dircolors`" alias ls='ls $LS_OPTIONS' alias ll='ls $LS_OPTIONS -l' alias l='ls $LS_OPTIONS -lA'
vi /etc/vim/vimrc and comment out the following line:
syntax on
and some more set’s from the bottom of the file as you like.
Note: If you are not familiar with vi/vim you can use nano to edit all files.
Performance tuning
Performance with default settings was really bad. Disk read and write was around 30MB/s to ext4 and SSH was laggy. After a few minutes I have found the issue. Per default OMV sets the conservative governor. This may work well with x86 CPUs or other ARM CPUs but with Odroid it is a pain.
In the web interface under “Power Management” is an option called “Monitoring – Specifies whether to monitor the system status and select the most appropriate CPU level.” This sounds quite good, problem is this option sets the cpu governor to conservative. Conservative governor with default settings works really bad on Odroid in combination with I/O.
Disabling this option sets governor to performance. All 8 cores at max clock speed the whole time produce quite a bit of heat (fan spinning a lot) and it is not really energy efficient.
CPU governor
But no problem we can change the governor to ondemand and with a little bit tuning your Odroid will fly. The following settings will replace conservative with ondemand governor if you enable the Power Management option.
vi /etc/default/openmediavault and append the following lines to this file:
# Ondemand Scheduler OMV_CPUFREQUTILS_GOVERNOR="ondemand"
Then regenerate the config with
omv-mkconf cpufrequtils
Note: There seems to be a bug in OpenMediaVault. After disabling Power Management and enabling it again it does not change cpu governor anymore. To fix this do the following:
update-rc.d cpufrequtils defaults
Ondemand governor tuning
I did a few benchmarks and this showed I/O performance (my main focus) depends a lot on the cpu frequency. Therefore we further have to tune ondemand governor to get full I/O throughput. To do so do the following:
apt-get install sysfsutils vi /etc/sysfs.conf
Copy the following to this file
# cpu0 sets cpu[0-3], cpu4 sets cpu[4-7] devices/system/cpu/cpu0/cpufreq/ondemand/io_is_busy = 1 devices/system/cpu/cpu4/cpufreq/ondemand/io_is_busy = 1 devices/system/cpu/cpu0/cpufreq/ondemand/sampling_down_factor = 10 devices/system/cpu/cpu4/cpufreq/ondemand/sampling_down_factor = 10 devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold = 80 devices/system/cpu/cpu4/cpufreq/ondemand/up_threshold = 80
Afterwards change to ondemand governor and activate these values with
cpufreq-set -g ondemand -c 0 cpufreq-set -g ondemand -c 4 service sysfsutils start
I did benchmarks with all these settings and for me this is the sweet spot. Nearly same performance as performance governor but lower frequency and less power consumption when idle.
Some explanation of all 3 settings:
sampling_down_factor: this parameter controls the rate at which the kernel makes a decision on when to decrease the frequency while running at top speed. When set to 1 (the default) decisions to reevaluate load are made at the same interval regardless of current clock speed. But when set to greater than 1 (e.g. 100) it acts as a multiplier for the scheduling interval for reevaluating load when the CPU is at its top speed due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its top speed when truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower speeds/lower CPU loads.
up_threshold: defines what the average CPU usage between the samplings of ‘sampling_rate’ needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of ’95’ it means that between the checking intervals the CPU needs to be on average more than 95% in use to then decide that the CPU frequency needs to be increased.
io_is_busy: if 1 waiting for I/O will increase the calculated cpu usage. The governor will calculate iowait as busy and not idle time. Thus cpu will reach higher frequencies faster with I/O load.
NTFS mount options
Besides the ondemand governor we will add the big_writes mount option to all NTFS mounts. In addition we will add noatime.
big_writes: this option prevents fuse from splitting write buffers into 4K chunks, enabling big write buffers to be transferred from the application in a single step (up to some system limit, generally 128K bytes).
noatime this option disables inode access time updates which can speed up file operations and prevent sleeping (notebook) disks spinning up too often thus saving energy and disk lifetime.
vi /etc/default/openmediavault and append the following
# Optimize NTFS Performance OMV_FSTAB_MNTOPS_NTFS="defaults,nofail,noexec,noatime,big_writes"
Then you have to unmount, apply, mount, apply all your NTFS volumes in the web interface.
With default mount options you get around 16 MB/s write. With big_writes you get up to 62 MB/s write. See this comparison below:
This looks fairly fast but keep in mind NTFS is very cpu intensive on such a system. Therefore real network throughput via samba (which is cpu heavy as well) is way less compared to a native linux filesystem. I tested this disk with samba and measured only ~30MB/s read and write speeds. This is considerably less than a native linux filesystem (see Samba benchmarks).
If you want to get full performance you have to use a native linux filesystem like ext4 or xfs. You really should!
More Monitoring
I really like the monitoring setup of OMV with rrdtool. Nevertheless I miss 2 graphs which I am interested in. It would be nice to have CPU frequency and CPU temperature graphs, therefore I extended the existing monitoring plugin.
Monitoring cpu frequency is no big deal because there is a native collectd plugin for CPU frequency. For CPU temperature we have to write our own collectd plugin which looks like this:
#!/bin/sh # Read CPU temperature of ODROID-XU3/4 # There are 2 sensors available: # /sys/devices/virtual/thermal/thermal_zone0/temp # /sys/devices/10060000.tmu/temp HOSTNAME="${COLLECTD_HOSTNAME:-localhost}" INTERVAL="${COLLECTD_INTERVAL:-60}" while sleep "$INTERVAL"; do VALUE="$(($(cat /sys/devices/virtual/thermal/thermal_zone0/temp)/1000))" if [ $? -ne 0 ]; then VALUE="U" fi echo "PUTVAL \"$HOSTNAME/temperature/temperature-cpu\" interval=$INTERVAL N:$VALUE" done
In addition to the script above you have to create new collectd configs and additional tabs in the web interface. I have done all that and uploaded the full sourcecode (including the script above) to GitHub: https://github.com/Obihoernchen/openmediavault-monitoring-odroid-xu4
Install these CPU frequency and temperature monitoring plugins with the following commands:
cd /tmp wget https://github.com/Obihoernchen/openmediavault-monitoring-odroid-xu4/archive/master.zip unzip master.zip cd openmediavault-monitoring-odroid-xu4-master cp -R usr/* /usr cp -R var/* /var rm -r /tmp/openmediavault-monitoring-odroid-xu4-master chmod +x /usr/local/bin/cputemp /usr/share/openmediavault/mkconf/collectd.d/cpu{freq,temp} omv-mkconf collectd chown openmediavault:openmediavault /var/www/openmediavault/js/omv/module/admin/diagnostic/system/plugin/Cpu{Temperature,Frequency}.js chmod 644 /var/www/openmediavault/js/omv/module/admin/diagnostic/system/plugin/Cpu{Temperature,Frequency}.js source /usr/share/openmediavault/scripts/helper-functions && omv_purge_internal_cache
The default diagrams are a little small for my taste, that is why I have increased the size a bit:
vi /etc/default/openmediavault and add the following to this file
# RRDTool graph width and height OMV_COLLECTD_RRDTOOL_GRAPH_WIDTH=800 OMV_COLLECTD_RRDTOOL_GRAPH_HEIGHT=200
Afterwards update OMV’s config files with
omv-mkconf collectd omv-mkconf rrdcached
Afterwards you will have 2 new tabs which show graphs like these:
Finally reboot to see if everything is working as expected.
Benchmarks
All benchmarks were done with performance governor to get consistent results.
Disks
I have several USB disks connected to my Odroid. Expect one disk all are 2.5″ USB 3.0 disks. All USB 3.0 disks are connected to two active USB 3.0 hubs. The USB 2.0 disk is connected to the USB 2.0 port.
In the following you can find hdparm read and dd read/write benchmarks for all connected disks. As you can see the performance is quite good and should be near the maximum the disks can handle.
### Overview of HDDs ### sda USB 2.0 NTFS w big_writes WD Elements 2,5" - 500GB sdb USB 3.0 NTFS w big_writes Toshiba Canvio Basics - 2TB sdc USB 3.0 ext4 WD Elements 2,5" - 2TB sdd USB 3.0 ext4 Toshiba Stor.E Basics - 2TB sde USB 3.0 ext4 CnMemory Zinc 2,5" - 1TB ### hdparm results ### hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 1846 MB in 2.00 seconds = 924.41 MB/sec Timing buffered disk reads: 74 MB in 3.06 seconds = 24.22 MB/sec hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 1370 MB in 2.00 seconds = 685.57 MB/sec Timing buffered disk reads: 240 MB in 3.52 seconds = 68.26 MB/sec hdparm -Tt /dev/sdc /dev/sdc: Timing cached reads: 1898 MB in 2.00 seconds = 950.68 MB/sec Timing buffered disk reads: 306 MB in 3.01 seconds = 101.61 MB/sec hdparm -Tt /dev/sdd /dev/sdd: Timing cached reads: 1960 MB in 2.00 seconds = 981.68 MB/sec Timing buffered disk reads: 248 MB in 3.01 seconds = 82.50 MB/sec hdparm -Tt /dev/sde /dev/sde: Timing cached reads: 2024 MB in 2.00 seconds = 1013.57 MB/sec Timing buffered disk reads: 318 MB in 3.02 seconds = 105.41 MB/sec ### dd results ### # sda dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 41.4705 s, 25.9 MB/s echo 3 > /proc/sys/vm/drop_caches && dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 44.1483 s, 24.3 MB/s # sdb dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 17.609 s, 61.0 MB/s echo 3 > /proc/sys/vm/drop_caches && dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 12.2101 s, 87.9 MB/s # sdc dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 12.9431 s, 83.0 MB/s echo 3 > /proc/sys/vm/drop_caches && dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 12.1161 s, 88.6 MB/s # sdd dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 10.2158 s, 105 MB/s echo 3 > /proc/sys/vm/drop_caches && dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 12.531 s, 85.7 MB/s # sde dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 11.9007 s, 90.2 MB/s echo 3 > /proc/sys/vm/drop_caches && dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 9.95148 s, 108 MB/s
Network
All network settings are default OMV/debian settings.
Receive: 832 Mbit/s = 104 MByte/s
Send: 896 Mbit/s = 112 MByte/s
I am satisfied with these results as it is close to the theoretical maximum of 1Gbit/s.
# Server on Odroid iperf -s -N # Client on Thinkpad T430 # bidirectional test individually iperf -c 192.168.0.2 -i 2 -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.0.2, TCP port 5001 TCP window size: 323 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.0.118 port 56182 connected with 192.168.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0- 2.0 sec 200 MBytes 838 Mbits/sec [ 5] 2.0- 4.0 sec 198 MBytes 831 Mbits/sec [ 5] 4.0- 6.0 sec 198 MBytes 829 Mbits/sec [ 5] 6.0- 8.0 sec 198 MBytes 831 Mbits/sec [ 5] 8.0-10.0 sec 200 MBytes 838 Mbits/sec [ 5] 0.0-10.0 sec 994 MBytes 832 Mbits/sec [ 4] local 192.168.0.118 port 5001 connected with 192.168.0.2 port 44967 [ 4] 0.0- 2.0 sec 207 MBytes 868 Mbits/sec [ 4] 2.0- 4.0 sec 215 MBytes 902 Mbits/sec [ 4] 4.0- 6.0 sec 216 MBytes 905 Mbits/sec [ 4] 6.0- 8.0 sec 214 MBytes 896 Mbits/sec [ 4] 8.0-10.0 sec 216 MBytes 907 Mbits/sec [ 4] 0.0-10.0 sec 1.04 GBytes 896 Mbits/sec # bidirectional test simultaneously iperf -c 192.168.0.2 -i 2 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.0.2, TCP port 5001 TCP window size: 289 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.0.118 port 56187 connected with 192.168.0.2 port 5001 [ 4] local 192.168.0.118 port 5001 connected with 192.168.0.2 port 44808 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 2.0 sec 125 MBytes 523 Mbits/sec [ 5] 0.0- 2.0 sec 100 MBytes 420 Mbits/sec [ 5] 2.0- 4.0 sec 109 MBytes 456 Mbits/sec [ 4] 2.0- 4.0 sec 110 MBytes 462 Mbits/sec [ 4] 4.0- 6.0 sec 112 MBytes 470 Mbits/sec [ 5] 4.0- 6.0 sec 108 MBytes 454 Mbits/sec [ 4] 6.0- 8.0 sec 118 MBytes 496 Mbits/sec [ 5] 6.0- 8.0 sec 105 MBytes 441 Mbits/sec [ 5] 8.0-10.0 sec 104 MBytes 436 Mbits/sec [ 4] 8.0-10.0 sec 119 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 526 MBytes 441 Mbits/sec [ 4] 0.0-10.0 sec 587 MBytes 490 Mbits/sec
Samba
Disk and network speed looks fine. Because there are windows machines in my network I have to use samba to share files. As you can see samba speed is quite good and very stable.
Writing 2.7 GB test file to Odroid (USB 3.0 ext4 disk)
Reading 2.7 GB test file from Odroid (USB 3.0 ext4 disk)
If you have any additional questions feel free to ask 🙂
I will try to update this post regularly with new optimizations etc.