New approach for Raspberry Pi OMV images

Important to know for RPi B 3+ users!

Now that we provide a new OMV image for RPi that also contains an updated ThreadX (that's the primary operating system running on all RPi euphemistically called 'firmware') and updated kernel+device-tree stuff booting the OMV image on latest RPi is possible. If you're interested in all the hassles and details here you go: https://forum.openmediavault.org/index.php/Thread/22185

The important bits:

• On first boot we limit RPi B 3+ to just 600 MHz since an awful lot of RPi installations uses insufficient powering leading to voltage drops under load that result in instable behaviour (freezes, crashes, kernel panics, data corruption). Staying at 600 MHz results in lower consumption so under-voltage can not be triggered that easy. After the installation has been finished and the Pi reboots one time, OMV checks for under-voltage and only if this hasn't occured RPi 3 B+ will be unlocked to full performance (1400 MHz).
• By default networking on RPi B 3+ will remain at 100 Mbits/sec. An awful lot of users replacing an older Pi with their new 3+ uses insufficient Ethernet cabling resulting in lower throughput and/or weird network problems. If you think this is not an issue in your installation feel free to edit one single config file to allow for Gigabit Ethernet (though speed improvements are not that great anyway, it's still 'shared USB2' and GbE NAS performance will be only a fifth of what all the better ARM boards provide)

For all the following steps you need SSH access to your OMV box or display and keyboard. In any case use the web interface first and create there a new user account being member of both 'sudo' and 'ssh' groups. Afterwards you can login with this user through SSH (e.g. using the Putty program on Windows, built-in ssh command everywhere else) or at the console.

To check for under-voltage do a 'sudo cat /var/log/raspihealth.log' or 'sudo raspimon' as explained on the first page of this thread. If you have an issue you need to fix it. This is a hardware issue. Buy a good PSU providing a stable 5.2V to your board, for example the official RPi PSU if you haven't already. Amperage ratings of the PSU are more or less irrelevant as long as they exceed 2A since the RPi problem is called 'voltage drop'. The power circuitry is that bad that you can't feed more than 2A anyway so all you have to take care of is a stable voltage provided to your Pi (cheap PSU don't, average Micro USB cables don't -- that's why a good PSU with a fixed and thick cable with low resistance is mandatory)

In case you want to enable Gigabit Ethernet you need to edit /etc/rc.local and put a '#' in front of the ethtool line. So you do a 'sudo nano /etc/rc.local', navigate to the bottom and edit the line so it reads like this afterwards:

# /sbin/ethtool -s eth0 speed 100 duplex full autoneg on

Save the file and reboot. If you now run into instabilities you're affected by under-voltage (Gigabit Ethernet increases idle consumption by approx. 500mW, load consumption slightly more since more data will be transmitted in less time). Switching back to Fast Ethernet will help, using a switch that is capable of EEE/IEEE 802.3az will help too (numbers)

If your network performance is now worse than before then you have an issue with cabling. Gigabit Ethernet uses 4 cable pairs while Fast Ethernet only 2. You can have cables that work very well with 100 Mbits/sec and you achieve 95 Mbits/sec transfer speeds in this mode while activating Gigabit Ethernet with the same cables can result in way lower numbers and tons of retransmits (since the other 2 cable pairs are the problem) or even no connection any more at all (rare).

To check for this use iperf3 (not iperf) since this tool lists not only transfer numbers but also count of retransmits (those retransmits trash the performance: TCP/IP just like any other protocol suite uses checksums to ensure data integrity. If data got corrupted at the wire the receiver takes notice and forces the sender to retransmit the packet. The more retransmits the lower the throughput. To get an idea on what's happening at lower layers -- Ethernet frames instead of TCP/IP packages -- you could run for example iperf3 in UDP mode)

And for anyone ever questioning our decision to limit RPi 3 B+ to Fast Ethernet by default... just read through this sad story: https://www.raspberrypi.org/fo…hp?f=63&t=208512&start=25 (archived version)

RPi users refusing both to test appropriately and to accept reality. If you have retransmits you have to get rid of them. Check your cable, check your switch port, eliminate the retransmits and then performance won't suffer any more.

People who are not network experts most probably will never get the idea that latency and round-trip times matter with lost packets, that any USB2 attached Gigabit Ethernet behaves totally different compared to any real Gigabit Ethernet implementation on the other SBC and that retransmits affect connections with high round-trip times a lot more than those with short ones (higher latency adds to lower throughput when packet loss occurs -- that's simple network basics).

Maybe I should remove the instructions above how to get the ethtool call out of the way to save us from unnecessary support hassles with reluctant RPi users? Anyone choosing a Raspberry Pi as NAS is not interested in NAS performance anyway. Fast Ethernet is totally fine for this target audience

Zitat von dogg!~

let people know that time machine backups would not work when I enabled gigabit ethernet

TimeMachine backups work pretty well with Gigabit Ethernet on single board computers. Personally tested with these boards: Banana Pi, Banana Pro, Olimex Lime 2, Clearfog Pro, EspressoBin, Rock64, Orange Pi Plus 2E, ODROID HC1 and HC2 and an i.MX6 Wandboard.

I don't see a reason why it shouldn't work also with the new Raspberry Pi. Are you sure you're not running in underpowering issues (Gigabit Ethernet needs more juice)? Care to provide output from 'armbianmonitor -u' and 'cat /var/log/raspihealth.log'

Zitat von dogg!~

I think my power supply is ok. below is the screenshot of cat /var/log/raspihealth.log

Yeah, no under-voltage occured so far. You might want to check this thread here discussing network problems with the new Pi: https://www.raspberrypi.org/fo…80e47fb2f880a197&start=50

Please remember: on every 'network equipped' Raspberry Pi there's no network in reality. It's always an integrated USB Ethernet adapter behind an USB hub (which is something you usually want to avoid). And USB on the Raspberry Pi has been a sh*t show since the early days: https://www.element14.com/community/thread/19436 -- reading through this from back in the early days it seems like a wonder that this worked somehow at all in the following years

Unfortunately you did not provide output from 'armbianmonitor -u' yet -- yeah, it really sucks trying to support this RPi OMV image

Please keep in mind that the most important components that had to be replaced to get the new Pi working are

• ThreadX (that's the primary operating system running on those raspberries that's called euphemistically 'firmware' or 'bootloader')
• Kernel (using the Pi Foundation's one)

So in case you run into the same problems with your old Pi 3 you might want to 'downgrade' those packages. You should be able to install those with 'dpkg -i'. Old ThreadX, older kernel. No idea whether the Foundation packages this stuff correctly so that downgrades work. Cloning the SD card or at least creating an image prior to anything like that is highly recommended.

Zitat von dogg!~

here you go

Thank you. There's nothing suspicious in the logs wrt USB or network but I spotted another detail I missed before: @votdev provided a new Netatalk package in the meantime, it's 3.2.11 now. So what's different between last RPi image and current one (having in mind that most people do not upgrade packages): ThreadX AKA firmware, kernel and Netatalk version. The older package is still available.

Please report whether things change on your older RPi 3

BTW: The funny moderator over in RPi forum loves to censor my posts there and to ban my account. I assume I've been posting the last time over there since he already warned me I get a permanent ban the next time

Anyway, there are some 'cheapest SBC possible with Gigabit Ethernet behind USB2 hub numbers' so they can get an idea how it should look like vs. RPi 3 B+: https://www.raspberrypi.org/fo…=208512&start=50#p1293648 (in case my post gets deleted as expected you find an archived version here at the bottom and here the next page of the thread -- and of course they CENSORED again, see my last post at the bottom that got deleted within 3 minutes . Really funny that they don't want to solve their own USB related problems but prefer to keep their users clueless)

Small follow-up on raspberrypi.org/forums/viewtop…=208512&start=50#p1293648

When testing with the cheapest SBC I have (Orange Pi Zero) with RTL8153 Gigabit USB dongle I got stable 323 Mbits/sec in both directions. With a VIA 813 hub in between Orange Pi and the Ethernet dongle it's 312 Mbits/sec receive (RX) and 319 Mbits/sec transmit (TX). Always zero retransmits.

Tested now with latest OMV image for RPI with my RPi 2 with same setup (same external USB2 attached RTL8153 network, same switch, same MacBook) and get 289 Mbits/sec RX and 298 Mbits/sec TX. So really no idea why Raspberry Pi folks call the lousy 220 Mbits/sec they get with tons of retransmits 'fine'. But doesn't matter anyway, since Raspberries are nothing you want to build a NAS with. Time to move on to something more interesting

Zitat von dogg!~

ok i'm back on the rpi3 -- so far no issues with your new image. could be the new board or the new pi3b+ in general

Hmm... really strange. On the new board they replaced the combined hub/Ethernet chip with something new (see comparison). Maybe that's the culprit? Anyway, don't care any more. Too much time wasted already with this incapable platform

Wrt other SBC that are way better suited as NAS: Which energy efficient ARM platform to choose?

And here's a 'SBC storage performance' update listing some SoC families: https://forum.armbian.com/topi…findComment&comment=51350 (Gigabit Ethernet on all those SoC families is all the time real -- 700-940 Mbits/sec -- and not USB2 crippled. On USB2 boards then of course storage will be the bottleneck. But unlike RPi 3 B+ with 'shared USB bus' you then get at least almost 40 MB/s NAS throughput and not just the half)

Zitat von tkaiser

Anyway, there are some 'cheapest SBC possible with Gigabit Ethernet behind USB2 hub numbers' so they can get an idea how it should look like vs. RPi 3 B+: raspberrypi.org/forums/viewtop…=208512&start=50#p1293648 (in case my post gets deleted as expected...

And of course it happened.

The new RPi 3 B+ has a severe network performance problem manifesting in very low throughput in RX direction and tons of retransmits. If we follow @dogg!~ then there are even functional deficiencies now with the new hardware (TimeMachine). How to deal with this problem? Solve it? Or better ban those people reporting info and providing insights? The latter and of course then also censor the information they provided.

See my post at the bottom here: https://archive.fo/Msrtx -- simple proof what's to be expected with USB2 attached Gigabit Ethernet (+300 Mbits/sec, NO retransmits). Why on earth has this to be deleted? Reality looks like this: any cheap $7 SBC achieves 320 Mbits/sec with USB2 attached Gigabit Ethernet, the new RPi 3 B+ fails. How to deal with this? Ban people and censor contents. It's really funny that censors are that 'smart' and don't think a second about all their actions being documented

Anyway: there's really no need to invest one more second in anything RPi related. The way the vendor deals with problems and the overall crappy performance permits any more development efforts for this platform (at least I won't waste my time any more).

Problem known since the early days. Their censorship and 'banhammer' methods prevent progress since the beginning and made it even into technical books...