New approach for Raspberry Pi OMV images

Quote from flmaxey

Off topic

No, this is not off-topic.

This only demonstrates how a specific device vendor deals with ovbious problems. They try to ignore as long as they can and blame everyone else around instead of their own product (see what the 'Principal Software Engineer at Raspberry Pi (Trading) Ltd' tries to point out: 'TBH, Microchip should be sorting this sort of thing out - it's their chip, firmware and driver'. They chose a new USB/Ethernet chip, they never tested this thing obviously and now they blame the chip vendor. And at the same time they delete every post in their forum that shows them the problem -- crappy performance in RX direction with tons of retransmits -- and they not even follow most basic troubleshooting advise. Are you f*cking kidding me?)

Given that the Raspberry Pi platform suffers from weird USB problems since day one it's really inacceptable that they blame the chip they attach to their somewhat special USB implementation. And then there's always the closed source problem. The main operating system on these boards is an RTOS called ThreadX for which no source access is available. If the problem has to be fixed there... no one outside the mythical Foundation or RPi Trading can do anything (RPi was never and will never be Open Source Hardware, it's the most closed SBC platform I ever dealt with).

Given that RPi Trading's only mission is to sell mediocre hardware to clueless people there are not that many incentives to make the RPi world an open place. Keeping their users clueless (censorship, banning critical voices) is just a logical consequence.

Another user took over and tried to raise basic awareness for the problem they try to ignore so hard: https://www.raspberrypi.org/fo…e134e86&start=75#p1294035 (archived version here in case they again do what they do all the time: censor everything that doesn't fit into the 'RPi is great' illusion).

242 Mbits/sec in RX direction and still retransmits is still a massive indication for a very basic problem (if you don't get at least 310 Mbits/sec with USB2 attached Gigabit Ethernet there's something seriously wrong!). And if @dogg!~ is right and his TimeMachine problems even occur with Ethernet set to 100 Mbits/sec on the RPi 3 B+ while everything works fine with 3 B then they should start to focus on their weird USB implementation and integration with Microchip LAN7515 (prior to that it was LAN9514 -- comparison).

But suffering from a typical Dunning-Kruger syndrome problem (enabling people on RPi Trading's payroll to censor expecting allegiance for their mediocre hardware) this will take ages and prevent smart people helping in the process. And even if they can solve their very own USB problems another time it still changes nothing and any Raspberry Pi as NAS is worst SBC choice possible. There is only one single USB2 connection to the host which slows down everything as hell. Gigabit Ethernet in such a situation was already known to become a problem.

Quote from flmaxey

@tkaiser is clearly right about the mismanaged tech aspects of the 3B+ project

Well, based on official statements from RPi Foundation and RPi Trading they didn't give a sh*t about anything network related at all prior to the product launch.

The numbers they provide on their announcement are plain BS. The wireless numbers are from some random LibreELEC developer who tested once at home and reported '102 Mbits/sec' for 5 GHz. When we did our own testings we got 230 Mbits/sec in one direction and an overall throughput of up to 330 MBits/sec with an 802.11ac AP ('we' means the large SBC community, not the brainwashed RPi forum community). So obviously no-one at that mythical Foundation or their commercial counterpart did any serious wireless testing.

The numbers they provided for Gigabit Ethernet are 315 Mbits/sec in both directions while until now no-one in the wild was able to exceed 245 Mbits/sec in RX direction. Without flow control the hard limit seems to be at 220 Mbits/sec now on the new board with Gigabit Ethernet. And unlike they want you to believe this is NOT an USB2 limitation but something new and special on their new board.

The level of ignorance/stupidity with everything Raspberry Pi related is really amazing. The 'Principal Software Engineer at Raspberry Pi (Trading) Ltd.' wrote this yesterday: 'Even once fixed, I would expect that the transfer rate will be on average about 230Mbits/s or thereabouts, that's the speed I get without retransmits. The USB2 bus simply doesn't have the bandwidth to deal with much more than that'

That's the same person deleting postings there all day long. And just hours before they deleted my last posting where I showed him the USB2 bandwidth limits with capable hardware (an $7 Orange Pi Zero). Even with a hub in between board and GbE dongle you're good for more than 315 Mbits/sec (see last post of the archived thread). Even the lame RPi 2 with a Gigabit Ethernet dongle is good for around 300 Mbits/sec also in RX direction (see above -- I tested it personally). And the RPi folks still babble about '230 Mbits/sec' as a hard limit for USB2 connected Gigabit Ethernet. If they would at least read what they censor away this would already be a huge improvement.

Anyway, time to stop wasting my own time with this crappy hardware and everything related (OMV an Raspberries)...

And it's also great that they now babble over there in their forum how to get into workaround mode (switching from Gigabit Ethernet back to Fast Ethernet since only reliable operation mode now -- that's how I decided to let OMV operate by default on RPi 3 B+ already last week): https://www.raspberrypi.org/fo…208512&start=100#p1294365

When reading this I tried to waste my time again telling them how to do it better: https://github.com/ThomasKaise…b/master/etc/rc.local#L25

But first attempt resulted in this:

Funny! 'Banned' based on dynamic IP address After restarting my router it then looked like this

@ryecoaaron can you please one more time replace readme.txt for the RPi image: https://pastebin.com/raw/NFB200xP

They switched to a 4.14 kernel branch the day before yesterday which also means OMV installations should be upgraded to this kernel version on first boot automagically. Anyone reporting problems (like 'no Wi-Fi') with an RPi installation still being on 4.9 is a symptom of users not being patient and interrupting the first boot (or no network connectivity).

Quote from dogg!~

I'm still on 4.9.80-v7+ --- Maybe this is part of my issue on the 3b+

IIRC you started with the new image before they switched the kernel branch from 4.9 to 4.14. What happens if you do an 'apt update && apt upgrade'?

Quote from nunorgp

I am having the same issue with the same configuration, it seems the network connection is constantly dropping

So what? There exist SBC that do work as intended... On the first page of this thread there are some places listed where to look into in case of problems.

If you use the new Pi 3+ then you should be aware that this thing is a power hog (triggering underpowering issues more easily than before) and that this thing got the internal USB+Ethernet chip replaced with something that has obviously never been tested by the device vendor. You find somewhere here in this thread various links to a funny RPi forum thread dealing with network crappiness on the new Pi.

Quote from dogg!~

i tried apt update and apt dist-upgrade -- didn't upgrade

Then you somehow interrupted the first boot or booted without network connected. This should be fixed on subsequent boots but for whatever reasons it does not on the RPi images. I honestly don't care about this crappy hardware any more.

Somewhere in the forum I explained multiple times how such an image could be repared. Maybe you find the threads...

Edit: here is one: Not starting NFS kernel daemon: no support in current kernel on 3.0.94 RPI3

Quote from dogg!~

Still cutting out when transferring large files across my network

I suggested over in the funny RPi forum to look into EEE (energy efficient ethernet) and one of those guys who censor there (RPi Trading employees) IIRC said disabling EEE fixed similar issues for him. There's a proprietary magic word you can use in config.txt for this, please visit their forum and deal with ignorance/stupidity on your own

Quote from dogg!~

I think this fixed it.

That's good to know. At least it should be possible then to fix this issue without disabling EEE by a future driver update (With negotiated Gigabit Ethernet and without EEE the new RPi 3 B+ has an idle consumption way too high for the performance)

In case you want to buy my a beer: here you go