Raspberry Pi filesystem reliability with writes? And using an RPI for hosting?

[cdev]

I have been wondering what the best Raspberry Pi filesystem (Ext4 has been very reliable for me - although I have heard many good things about XFS.. but on the RPI, I dont know much about their pros and cons..)

I am lostly asking this question about hardware.. because flash cards have not been super reliable for me when I am using an RPI a lot. I am afraid to compile software on a machine that uses flash memory.. which I hate because I want to compile stuff on the machine its going to run on..

When lots of writes are happening, flash memory or an SSD may not be the best at all..

So to compile, just to have the disk to thrash and not worry, (Ive not tried cross compiling software yet)  I have been using external USB drives.. They seem okay for reliability. But its slow, of course, too. Would like to cross compile - everybody tells me thats the best way to do that. 

I'd love to be able to use an RPI4 with a physical spinning hard drive and have a known good setup for hosting web sites.

I suppose one could just use two external disks and software RAID. SATA drive performance is certainly good enough for almost all applications..

I wonder what the most demanding uses people have used the Raspberry Pi for server wise are so far?

They have lots more power now than the machines I started out doing web stuff on, thats for sure. Much Faster networking too.

I wonder how hosting a database on them would perform, probably no different than using other current platforms like amd64. Except ARM64 uses much less power..


If somebody puts  lot of energy into building a web site with say a gigabyte or more of content and hundreds of users, it sure would suck for it to be lost due to flash card unreliability due to lots of writes.. . I guess you just need to schedule frequent backups to other storage .  And verify that it is easy to recover from your backups too. The default settings of lots of software -logging especially I could see killing a flash card.. So best to use a mechanical disk. a 3.5 mechanical disk. or maybe two in a RAID configuration would probably be optimal.. Set to backup itself to a remote disk..

Small 2.5 hard drives in my experience are less reliable than full size ones. You can use extermal 3.5 disks connected via USB3 of course and that would likely be the best for performance too. , but of course they likely require a larger power supply. Then they can be very reliable. If they dont face any hard knocks or similar And are kept reasonably cool. (Optimal temps for hard drives may even be a bit warmer than average ambient temps in data centers, just not too hot)

I wonder if any real world Raspberry Pi users are using them for hosting any "busy" web sites, and if so, how its working out for them?

[DiTBho]

Small 2.5 hard drives in my experience are less reliable than full size ones

I bought qty=12 Hitachi 2.5" HDD in 2007. All still 100% working.
qty=20 IBM-travel-star 2.5" HDD. All dead.

So it depends on the brand, I think 

As far as I know, WD-redline, no matter if 2.5" or 3.5", is currently the best.
Barracuda 3.5" were a great deal four years ago, when they had the 250 and 500GB line. Now it's crap.


However, *my opinion*, SD-cards should only be used in read mode. To boot the kernel and for nothing more.

[cdev]

Thanks for that info!  What model was the reliable small drive?

Also, by Hitachi do you mean "HGST" ? (has good reputation as far as I can tell, now) But going back around a decade I had a "momentus" 2.5 IBM/Hitachi I think drive die a shameful death in a Mac. )

It turned out to be some BIOS error - their fault, they offered to replace it.. not a good situation I had lost important data on it.

Now I am backing up my drives as none of them last forever..

Generally most hard drives now seem much more reliable and quieter, too, than they were for me in the past.

Whatever happened to Maxtor? I still have some old Maxtor drives. The manufacturer doesn't seem to be making drives any more, or am I wrong?

[ve7xen]

The most reliable approach is going to be operating completely read-only at runtime. NanoBSD offers quite a nice set of tooling for building such a system, but I'm not sure about support for it on RPi. Running it on an industrial microSD should be extremely reliable and I wouldn't really worry about storage failure, assuming the SD peripheral/driver on them is actually itself reliable. Especially considering how janky and lashed together a RPi 'server' is going to be. I'm not aware of anything quite as slick on Linux, though of course it's possible to set everything up that way there too with a bit of effort.

I don't know why you'd use an RPi as a server for anything with many users / public access when cloud providers offer free virtual machines and for-pay web hosting is pennies per month.

If it's for local use as a NAS or whatever, I'd just treat it the same way I would a 'normal' home server. Boot from a good-quality SSD and attach rust as required. Though by the time you buy all the stuff (PCIe SATA card, PCIe RPi adapter, enclosure, PSU, etc.) you need to wedge an RPi into this role, I doubt it's cheaper, and is considerably less capable than buying a quality miniPC on CraigsList and installing FreeNAS on it.

[cdev]

Small 2.5 hard drives in my experience are less reliable than full size ones

I bought qty=12 Hitachi 2.5" HDD in 2007. All still 100% working.
qty=20 IBM-travel-star 2.5" HDD. All dead.

So it depends on the brand, I think 

As far as I know, WD-redline, no matter if 2.5" or 3.5", is currently the best.
Barracuda 3.5" were a great deal four years ago, when they had the 250 and 500GB line. Now it's crap.


However, *my opinion*, SD-cards should only be used in read mode. To boot the kernel and for nothing more.

When you shut down and save your work for the day, you just save it to a regular hard drive?

Where I live, once in a great while there are short power utages, ususally its back up fairly quickly.. A raspberry pi can run off of batteries all of the time, and doing that with 2.5 hard drives is also not difficult. Thats a big advantage when I think about it.

I often wonder if we, as a society culd switch to a more DC using lifestyle using DC in the home for almost everything, I bet we could. There is a huge risk that we are all living with of solar storms risk to the electric grid. A solar storm like the one in 1859 could wipe out power all around the world. It might even take months or years to bring it back up.  The disruption might even cause nuclear melt downs due to a problem called "loss of the ultimate heatsink" So maybe we as a society should just decide to switch to DC and then do it.  Or maybe we could set up some hybrid that would be optimized for resilience.

Its the AC to AC transformers that are the point of failure in solar storms, because of how the power distribution system is unbalanced by the DC pulse that comes from the Sun. It takes a few minutes to get here and right now they are counting on getting a few minutes warning from two spacecraft we have out there orbiting at the Lagrangian points monitoring the Sun for huge solar flares heading towards Earth. But thats a hell of a way to do something that's SO important.. There is, the best we can tell a one in eight chance or higher of a coronal mass ejection per decade..  The area that I live, the East Coast of the US is particularly prone to power system disruption due to an electromagnetic pulse of this kind, and we also have our share of Mark 1 design nuclear power plants, like the ones at Fukushima.. The rock under me is "igneous rock" which means its high in obsidian and does not conduct well, at all. There is no good grounding.  So they are known to be highly vulnerable to this potential disaster of they lose steady cooling power..

[cdev]

The most reliable approach is going to be operating completely read-only at runtime. NanoBSD offers quite a nice set of tooling for building such a system, but I'm not sure about support for it on RPi. Running it on an industrial microSD should be extremely reliable and I wouldn't really worry about storage failure, assuming the SD peripheral/driver on them is actually itself reliable. Especially considering how janky and lashed together a RPi 'server' is going to be. I'm not aware of anything quite as slick on Linux, though of course it's possible to set everything up that way there too with a bit of effort.

I don't know why you'd use an RPi as a server for anything with many users / public access when cloud providers offer free virtual machines and for-pay web hosting is pennies per month.

If it's for local use as a NAS or whatever, I'd just treat it the same way I would a 'normal' home server. Boot from a good-quality SSD and attach rust as required. Though by the time you buy all the stuff (PCIe SATA card, PCIe RPi adapter, enclosure, PSU, etc.) you need to wedge an RPi into this role, I doubt it's cheaper, and is considerably less capable than buying a quality miniPC on CraigsList and installing FreeNAS on it.

Power.. some people live where power is really expensive now.  They are trying to cut down on the watts a real lot, right?

It's not that bad here, yet but it may get that way, and anything that stays on all the time, it makes a big difference.

[PlainName]

which I hate because I want to compile stuff on the machine its going to run on..

Why is that? Would you want to compile stuff on a PIC because it's going to run on there? An ATTiny?

[Berni]

You can do hard drives on a RPi over USB pretty well, especially if you have a Pi with USB 3.0 ports.

For database performance you would want to use a SSD tho. Spinning rust does have unlimited write cycles and sequential read/write speeds up of up to 100 or 200 MB/s but the access times are horrendously slow. Databases tend to make tiny scattered accesses that HDDs are very slow at. But on a SSD the access time is near instant with the typical SSD capable of servicing about 10k to 100k write/read operations per second. This can make a massive difference in database performance (like 1000x faster). But but... i don't want to wreck my SSD with writes! Well on a decent quality modern SSD you get about 100 to 3000 TBW of rated lifetime. So for say a 1000TBW rated SSD you could write to it at max USB 2.0 speed of ~50MB/s for about 1 year continuously 24/7. You would need a very very busy database to write this much data. Also you do want to keep a backup of the database anyway. So what if you have to replace the SSD after 15 years of intense database use. The machine will likely get upgraded by then anyway.

However running a server on a RPi does not save as much as you might think. Sure the Pi is cheep and uses fairly little prower, but you can also get a old PC pretty cheep. That PC provides lots of good ways to install hard drives, it has a PSU for powering them built in, it can take SATA HBA PCIe cards to give it 24 SATA ports at full performance etc.. Power usage is also not that bad as modern PCs are pretty power efficient. For example my NAS is a 6th gen i5 machine that can consume as little as 10W when idle. For being a large file server the hard drives are going to be using more power than the computer itself. So you are not really saving much money by using a Pi since you have to buy extra crap that a PC comes included with while not being that much more power efficient. Backup power is also easy, just buy a UPS, even a little wimpy one can run such a light intel server for half an hour, it also has all the battery management inside it, so over USB your server can know exactly how much battery time it has remaining before having to start a shutdown procedure.

PCs are also very good at running VMs with near zero overhead. This is something that is very desirable for a server that is anything more than just a file server since you want to run things like web services inside a VM. This makes them easy to remotely manage, easy to backup, easy to recover from a backup, easily spin up a extra instance for testing of a change before deploying it to production (you don't want to crash the live production server by accident).

[David Hess]

I have been wondering what the best Raspberry Pi filesystem (Ext4 has been very reliable for me - although I have heard many good things about XFS.. but on the RPI, I dont know much about their pros and cons..)

I am lostly asking this question about hardware.. because flash cards have not been super reliable for me when I am using an RPI a lot. I am afraid to compile software on a machine that uses flash memory.. which I hate because I want to compile stuff on the machine its going to run on..

When lots of writes are happening, flash memory or an SSD may not be the best at all..

My understanding is that the problem is with flash memory which lacks power loss protection, so an SSD which does include power loss protection should not catastrophically fail.  Otherwise the risk of data loss is the same with a mechanical hard drive.

[wraper]

It's not that SD cards lack a power loss protection. Many memory cards cause file system corruption on RPi even without ever losing power. If you have problems with FS corruption RPi, switch memory card to something different. IME Sandisk always was the safest option. But some memory cards will outright refuse to work.

[DiTBho]

When you shut down and save your work for the day, you just save it to a regular hard drive?

If you are worried about random electricity turn-off, then you can evaluate the purchase of a UPS for a NFS//git server on a remote machine and push there your milestone commits on the RPI.

Eventually, even a laptop can be that kind of server. So you develop on the RPI, and you push git-files to the laptop.

[cdev]

Jeff Geerling seeems to have done a lot to answer my question here:



Now I need to get a Pi4 to be able to use PCIe

[cdev]

which I hate because I want to compile stuff on the machine its going to run on..

Why is that? Would you want to compile stuff on a PC because it's going to run on there? An ATTiny?

Because sometimes, using compiler flags gets me the wrong architecture optimizations, and "native" always is right for the machine you are using then.

[PKTKS]

Jeff Geerling seeems to have done a lot to answer my question here:



Now I need to get a Pi4 to be able to use PCIe

So far ... so good ... the idea of using PIs is tempting me a long time...

But the real thing is that (FOR NOW)... they will cost much much more to setup ...
A reliable NAS made by vanilla PC parts still is unbeatable...

Paul

[wraper]

Now I need to get a Pi4 to be able to use PCIe

For the price they currently sell for, IMHO it's better to stay away. I had like 150 of faulty and untested returns of Raspberry pi 3 laying around for years because I was to lazy to test and fix them. Then noticed for how much they go, started fixing and selling them at $60, they were simply flying away, gradually increased the price to $89, and they still were all gone in no time.

[DiTBho]

Jeff Geerling seeems to have done a lot to answer my question here:
Now I need to get a Pi4 to be able to use PCIe

That guy is there to make videos and makes money with that, and it's no surprise that most of what he says is bullshit. Like when he suggested buying a 1600 Euro PCIe controller and several HDs just to make a NAS-toy; or 1200 euro just to make a cluster-toy.

Edit:
Of course, it's just my opinion.

[Berni]

Jeff Geerling seeems to have done a lot to answer my question here:

Now I need to get a Pi4 to be able to use PCIe

In that case be prepared for a whole lot of Linux wizardry to get something like that working. You don't get drivers included for a lot of this stuff and adding one in is not 'just installing it'. If you are in it for the fun of messing with linux and have recompiled the kernel before sure go for it. If you just want a working server you will be cursing it.

All this linux setup malarkey is the reason while i just shelled out the money for a Unraid license for my PC based NAS server. Pretty much all of the functionality could be put together by loading up a linux install with the appropriate open source software and configuring it all to work together. It became clear that is more work than i am willing to put up. My time is more valuable than that. Especially for someone like me who knows enough about linux to be dangerous, but is far far from a linux expert that uses it daily, so sometimes even a seemingly simple task might be a frustrating evening to sort out.

After all a stack of brand new quality reliable hard drives easily costs half a grand, so it does not make sense to shave dollars off the whole project in exchange for punting many extra hours of work into it while ending up with a worse performing less reliable system.

[Nominal Animal]

I have been wondering what the best Raspberry Pi filesystem (Ext4 has been very reliable for me - although I have heard many good things about XFS.. but on the RPI, I dont know much about their pros and cons..)

It does not matter.  ext4, xfs, and even btrfs are all more reliable than the RPI hardware.

You see, the Broadcom SOC has a serious hardware issue: in certain situations, it can drop USB packets without telling anyone.  The Foundation has done a lot of work (by junior developers, as the senior developers do not associate with open source projects) to deal with this in software, but you cannot fix a silent hardware issue in software, not completely.

You'd be better off using an Amlogic S805 or S905 based SBC on Debian ARM port, as these have upstream Linux kernel support (including Amlogic employees contributing the support directly to the Linux kernel, instead of their own vendor kernels), and you can actually participate in the wider free/open source communities, instead of working inside the RPI community only.  Assuming reliability is a real concern, that is.  For a NAS box, minimize the Debian installation first, then only install what you need, and you get a pretty stable box.  For better stability, you'd need to switch to Devuan (Dev1) ARM port.

Me, I use xfs on large servers only; btrfs on Flash media and also when I want the features but don't want to use ext4 on top of LVM2 to get e.g. filesystem snapshot support (for coherent backups from running systems); and ext4 everywhere else.  On desktops, I use ext4 on top of LVM2 (since LVM2 provides most of the features people need xfs or btrfs for), but usually just ext4 on SBCs.

(Before anyone labels me an "anti-RPI nutjob", I do have a couple of RPIs myself, and half a dozen Amlogic S805/S905 variants, all of different types, from at least three different manufacturers [HardKernel, Orange Pi/Shenzhen Xunlong, Libre Computer, plus a TV box for hacking from H96].  However, I do have lots of Linux experience from all of its parts, including systems integration and distro development, so what I find useful might be different to what you need, so our experiences may well differ.)

[DiTBho]

You see, the Broadcom SOC has a serious hardware issue: in certain situations, it can drop USB packets without telling anyone. 

I remember a YouTube influencer saying so wonderful things about Allwinner's H5* that I decided to buy some H3 and H5 SoCs which *apparently work* but as soon as you look under the hood you find they actually have a buggy co-processor MPU and a buggy thermal management as well as wrong DRAM setting values in u-boot, an you need to disable all of them and hack both kernel and firmware stuff.

[cdev]

So for industrial settings, maybe not so good because they are prone to glichiness?

I recently got a (used) HP thin client for $20 that has a quad core AMD processor and radeon graphics.. Its small too. Thinking as using them as my super small go tobox..  The thing thats been putting me off the RPIS is the micro SD cards fail on me. Ive used flash drives on the thin client too, though I suspect that may happen to them too. It seems that I can probably put an SATA drive in them, with some difficulty and not a lot of cost. They have internal USB ports too, so can be closed up so the flash drive doesnt go anywhere. Seems like they draw around 2 or 3 amps. Just a bit more than an RPI. They come with gigabit Ethernet and are x86_64 compatible. They have a AMD processor with built in Radeon GFX  from a couple of years ago. Its not a speed demon but also its not that shabby, especially considering the price. Its a "real GPU" it shares graphics memory with the CPU, like the RPI.

I have been wondering what the best Raspberry Pi filesystem (Ext4 has been very reliable for me - although I have heard many good things about XFS.. but on the RPI, I dont know much about their pros and cons..)

It does not matter.  ext4, xfs, and even btrfs are all more reliable than the RPI hardware.

You see, the Broadcom SOC has a serious hardware issue: in certain situations, it can drop USB packets without telling anyone.  The Foundation has done a lot of work (by junior developers, as the senior developers do not associate with open source projects) to deal with this in software, but you cannot fix a silent hardware issue in software, not completely.

You'd be better off using an Amlogic S805 or S905 based SBC on Debian ARM port, as these have upstream Linux kernel support (including Amlogic employees contributing the support directly to the Linux kernel, instead of their own vendor kernels), and you can actually participate in the wider free/open source communities, instead of working inside the RPI community only.  Assuming reliability is a real concern, that is.  For a NAS box, minimize the Debian installation first, then only install what you need, and you get a pretty stable box.  For better stability, you'd need to switch to Devuan (Dev1) ARM port.  Thanks for that into. Devuan is more solid than Debian? Debian has lots of stuff that gets installed with Gnome that I dont want, thats for sure.

Me, I use xfs on large servers only; btrfs on Flash media and also when I want the features but don't want to use ext4 on top of LVM2 to get e.g. filesystem snapshot support (for coherent backups from running systems); and ext4 everywhere else.  On desktops, I use ext4 on top of LVM2 (since LVM2 provides most of the features people need xfs or btrfs for), but usually just ext4 on SBCs.

(Before anyone labels me an "anti-RPI nutjob", I do have a couple of RPIs myself, and half a dozen Amlogic S805/S905 variants, all of different types, from at least three different manufacturers [HardKernel, Orange Pi/Shenzhen Xunlong, Libre Computer, plus a TV box for hacking from H96].  However, I do have lots of Linux experience from all of its parts, including systems integration and distro development, so what I find useful might be different to what you need, so our experiences may well differ.)

Thank you!

[cdev]

Jeff Geerling seeems to have done a lot to answer my question here:
Now I need to get a Pi4 to be able to use PCIe

That guy is there to make videos and makes money with that, and it's no surprise that most of what he says is bullshit. Like when he suggested buying a 1600 Euro PCIe controller and several HDs just to make a NAS-toy; or 1200 euro just to make a cluster-toy.

Edit:
Of course, it's just my opinion.

A fairly well informed one too. Thanks!



I dont think he suggested that, and I think either the manufacturer or broadcom sent him the card temporarily because it seems he was helping them out by getting it working. Clearly he's not free to spend whatever he wants on the hardware he uses in his videos.. he talks about the cost and when manufacturers loan him equipment he mentions that. He's just a poor schmuck like most of us fooling around for fun and because he likes the platform, they are sort of toy computers. What I was trying to figure out in this thread was if they can be a little more than that.. without breaking the bank, and where the points of diminishing returns were located..

Here in the US the cost of electricity is rising quickly so the era of cheap natural gas and electricity (the price of which tracks natural gas) that I grew up with (since the ban on exporting liquid natural gas begun in 1975, it just ended last year... )  is ending, fast.
I am not in one of the worst areas at all but even here in the last few months my electricity bill has gone up by around 75% so this is a big concern for me. I'm replacing all my energy hog appliances. Cutting back on electricity and natural gas use.

Its fairly likely they will switch to nuclear energy. "Energy agnosticism" they call it in trade deals allows them to ignore what people vote for completely and just do more nuclear.  Or whatever they want.. coal.. Causing more mercury pollution. If you are female or have a femals spouse or sweetie of childbearing age, tell her to take NAC. n-acetyl-cysteine.. To prevent birth defects from glutathions depletion.. It also helps reduce the risk of covid and other things.. Its all because of a problem with the expression of two genes, "fyn" and "cCbl" - which are involved in cell differentiation in a developing fetus.. Having adequate amounts of intracellular glutathione is really important. So to suport your glutathione levels, take n-acetyl-cysteine. As we age we all should supplement with extra cysteine. NAC is the best kind totake. Its cheap too.

So, back to rising cost of energy..

People with electric cars, unless you also have lots of PV, its going to hit you too..You people who heat with electricity.. Thats too expensive for me, except limited to small heaters and heating pads.. 

[Nominal Animal]

So for industrial settings, maybe not so good because they are prone to glichiness?

It depends on the load.  Anecdotally, when the average I/O load is low, you're unlikely to get bitten by the USB glitches.

However, the Ethernet on them is also on the USB bus.  So, in NAS use, you're uncomfortably stressing the exact system part – the USB bus message management – that has the risk of the glitch.

For the last half year or so, I've been using WD Green 120 MiB and 240 MiB SATA SSD disks, with a cheap USB3-SATA adapter (<10€).
    ID 174c:1153 ASMedia Technology Inc. ASM2115 SATA 6Gb/s bridge
The trick with these is that since they are mass-produced, you may get a defective cable from the get go, so better thoroughly test one first (say, running some transfer tests for a couple of hours first) before relying on it.  Second is that with ASMedia, you want the :1153 version, and NOT :105x, which have buggy UAS support.
Similarly, several Jmicron controllers (dirt cheap, often looked down upon) are problematic, but most are absolutely fine.

What I like to do, is just stick the adapter to an USB port in my linux machine (without any disk attached), and run lsusb so see the manufacturer:device pair.  Then, I go to drivers/usb/storage/unusual_devs.h and drivers/usb/storage/uas-detect.h in the Linux kernel, and see if their USB Attached SCSI implementation is supported and/or known to have problems.  (If you know what kernel you're going to run, do select that particular version on the left.)

If you have a friendly local store, you may even ask them to check the manufacturer:product number of the actual adapter, and you can quickly do a search at Elixir over the net on those two linked pages, to see if the adapter should be supported and is known to have issues or not.

Anyone who feels that these adapters are less reliable than built-in stuff, do remember that this is exactly how SATA support is implemented in most SBCs, the adapter chip is just integrated on the board.  X86-64 AMD/Intel-based SBCs like Odroid H2, and HardKernel's Amlogic S905X3-based (ARM Cortex-A55) Odroid HC4 are an exception, as they usually have a native or PCIe-to-SATA chipset; Odroid HC4 uses good old ASMedia ASM1061 PCIe-to-SATA bridge instead.  (The reason I bought a H96 MAX X3 Android TV-box for under 40€ shipped from Banggood on sale, is because it too has a S905X3 SOC on it, but no SATA.  I might have to port and adapt some device tree descriptions and maybe even drivers from the Android kernel to get full vanilla Linux support, but it's nothing I haven't done before.  Sneaky, sneaky!)

[ve7xen]

The thing thats been putting me off the RPIS is the micro SD cards fail on me. Ive used flash drives on the thin client too, though I suspect that may happen to them too.

Consumer-grade flash isn't really designed for 24/7 use, nor the write count a typical OS will generate. Quality will vary widely and I wouldn't really expect any guarantee of reliability, even from A-brands. Counterfeits are a huge problem too, I wouldn't even trust 'sold by Amazon' to actually get you genuine parts.

For anything like this, I'd buy industrial grade flash that's designed for exactly this, embedded systems, whether it's USB, SD, or a small SATA module. There are still limits of course, but it's widely used in high reliability applications like enterprise-grade routers. Look for SLC-based microSD cards from Swissbit, ATP, or some of the major consumer vendors like Kingston and WD produce it too. Buy through trusted channels. DigiKey stocks ATP and Swissbit, for example.

[DiTBho]

It depends on the load.  Anecdotally, when the average I/O load is low, you're unlikely to get bitten by the USB glitches.

Do you know what it makes me to remember? The old W703 SoC. It has a similar problem between the integrated-Wifi and USB.

When the average transmission IO on the antenna is high, you're likely to get bitten by the USB glitches for - nobody knows, not even the science - interference or something.

Nice, ain't it? 

Official solution: disable the Wifi and power off the radio, there is no other way to patch/fix it.

[gmb42]

I have been wondering what the best Raspberry Pi filesystem (Ext4 has been very reliable for me - although I have heard many good things about XFS.. but on the RPI, I dont know much about their pros and cons..)

It does not matter.  ext4, xfs, and even btrfs are all more reliable than the RPI hardware.

You see, the Broadcom SOC has a serious hardware issue: in certain situations, it can drop USB packets without telling anyone.  The Foundation has done a lot of work (by junior developers, as the senior developers do not associate with open source projects) to deal with this in software, but you cannot fix a silent hardware issue in software, not completely.

Is this still true for the RPi 4?  I believe for that model the Ethernet controller is in the SoC and not attached to USB.