Orange Pi 5 Review – Powerful, No WiFi

Hey babacki,

You did a write test to /dev/null. The drives are well known to cheat writing to /dev/null. That isn’t a real result basically (it’s using drive optimizations, data is not going that fast over the interface, it’s just throwing the data away which takes less time than actually writing it giving you a ridiculously inflated effective speed for the test).

In other words this is a modern optimization. When things are written to /dev/null it’s smart enough to not try to actually write it anywhere. DD isn’t smart enough to tell you this though because it isn’t meant to benchmark storage performance on drives. It’s meant to do what you tell it to but that’s the issue. The operation you are telling it to do is a discard operation essentially and not a write operation.

DD just calculates the effective speed based on how fast the operation happened but you are measuring a discard and not a write so you have effectively benchmarked your discard speed to /dev/null here.

Can you try taking my benchmark at pibenchmarks.com with:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

Or alternatively can you do a proper DD write test like this:

dd if=/dev/zero of=test bs=4k count=80k conv=fsync

This is one the tests that my benchmark runs (it also runs fio and iozone tests). The difference is it writes pure zeroes to a file called “test” instead of /dev/null (which will give you a false reading). You would just want to make sure your working directory/folder you are in when running the above command is actually on the NVMe drive. Afterward it’s safe to remove the “test” file it generates.

Can you give one of those a try?

P.S. don’t feel bad about this. I see much larger content creators than myself benchmark things this way all the time but it is wrong. It’s literally one of the reasons I made pibenchmarks.com. Benchmarking your storage accurately is actually kind of tricky! It gets even more complicated when you realize that DD write performance (raw throughput) is actually much *less* important than random read/write performance.

Random read/write performance is small and frequent reads and writes all over the drive (this is how computers running dozens of applications / services actually work, they don’t write giant sequential blocks of raw data like the DD write test hardly ever other than imaging and backups, it’s in reality touching cache / log / config / other files spread out all over the drive constantly) and there aren’t any built in tools to measure that (but iozone and fio are fairly easily available usually via repositories). Random read/write performance will impact how fast your computer actually “feels” to use (when you click things how fast does it respond if it needs to touch the disk, stuff like that, you can literally feel it).

DD write does not capture this type of random read/write performance but it’s important because it requires more expensive components. SD card / SSD / drive manufacturers love to print those big giant sequential write numbers on the box and will really squirm if you try to get the random read/write performance out of them (because that relies on them using good cache and a high quality storage controller and those are expensive).

If you have upgraded from a HDD to a SSD for example and then try to go back to using a HDD things will feel miserable (which can’t be explained by the sequential I/O transfer speeds which on the best HDDs can still rival many SSDs and are still widely used in enterprise/video/backup/more and those drives will still feel icky being used as the OS drive). It’s explained by the higher random read/write performance of SSDs vs. HDDs (because SSDs don’t have mechanical moving parts that can’t be in multiple places at once so that definitely helps when trying to jump all over the drive randomly reading/writing). That’s what I mean by “feeling” the difference for sure (in time and responsiveness).

Hopefully that helps!

Hey babacki,

You don’t understand. You are still using storage optimizations because you are writing the NVMe drive to itself. It doesn’t have to transfer that data over the PCIe interface because it’s already on the drive! The drive also has a *cache*.

This is why you write zeroes. The zeroes aren’t already on the drive. Your tests are completely meaningless here. Do you understand how caching works? A lot of the data from the drive is in the cache! You’ve completely invalidated the first test.

This is so funny. You are now down to 280Mb write and you are still running the test wrong. You are writing it as

of=/dev/nvme0n1

Nice, so you’re telling me to run this test you wiped out the entire partition table and just wrote raw zeroes to the NVMe drive. You didn’t write it to a file? Except that’s what we’re testing! You aren’t running my test.

Why didn’t you post my test results? Surely you ran my test command. Why not? You’ve also tweaked the block sizes. Do you understand that can make a difference as well?

Your improperly ran test is down to 280MB. I’m feeling better and better. Please run the same one everyone else has and post that which you intentionally avoided doing (and I know why). I don’t think I’ll believe you at this point though unless you test on pibenchmarks.com.

Dude, this is 280MB performance now you’ve backed yourself into a corner with and it’s only going to drop when you start taking the rest of your other flags off and do the same test as everyone else (how long did you experiment with these to try to find ones that would let you go over 250) off of your test. Come on. The dude that is writing to /dev/null for a performance test is the genius schooling me about DD write performance. You have already proven you don’t know what you’re doing man. It’s not a secret or my opinion that /dev/null is a bad write test. You’ve even basically admitted you see that now that methodology is flawed (that’s putting it mildly, it’s a completely nonsense bogus wrong test).

You also need to run THE SAME test as everyone else for it to mean anything. This cherry picking of the flags and tweaking the blocksize is really desperate. I’m afraid I’m going to have to insist that you take the benchmark publically on pibenchmarks.com because you’re already messing with flags, blocksizes and everything to try to make yourself look right here. You’re not. This is bad testing.

Why don’t you just go be happy with your 280MB/s blazing speeds. Everything is fine right! None of us have other boards and have any idea what PCIe 2.0 performance looks like. Genius babacki the storage expert doing his DD write tests to /dev/null is here to tell us it’s fine. You aren’t even smarter than the SSD. You don’t even understand the optimizations it’s doing (you still don’t by the way, not even now, that’s what I’m trying to tell you).

Why do you have to convince me? That’s going to be difficult because I test these *all the time* and I have boards that do PCIe 2.0 and PCIe 3.0. This board ain’t one of them.

I think either Orange Pi or we will fix it eventually but if you don’t see that it is not performing at PCIe 2.0 speeds you are absolutely hopeless at this point. People are already working on solutions and you can’t even figure out there’s an issue. We’re way past that man, we figured it out weeks ago!

The Orange Pi 5 is not the only board that has PCIe 2.0 as a capability. We can literally compare it to other boards like the Radxa boards where you use the overlay to enable PCIe 2.0. It’s not your terrible speeds that people get with the PCIe 2.0 overlay activated on other boards. This is not a guess. Other people than me here know this and have been working on it for days. They aren’t flirting with the PCIe 1.0 cap like your desperate tests here. You just don’t understand the optimizations being applied and you refuse to run a real benchmark (because those ones ARE designed to measure it and will prove you wrong).

Are you really so confident that there isn’t another 30MB of optimizations going on here after your first benchmark? Why? Why should we believe you when you have already *proven* you have NO idea how to benchmark these?

Hey babacki,

Which ones should we start with? Why did you choose conv=fdatasync for your test? That’s an interesting choice. Do you know what it does?

fdatasync - physically write output file data before finishing
fsync - likewise, but also write metadata

Alright so you downgraded writing the metadata. That’s already an optimization right off the bat that will not be reflective of actual file write performance. Fortunately that probably won’t have much of an impact when you’re straight up wiping out the NVMe drive by writing zeroes directly to the device rather than a file. What metadata is there when you just wipe out the entire drive with 0s?

Why did you use a 1M block size? That’s another interesting choice. Do you know why we use the blocksize 4096?

root@orangepi5:~# blockdev --getbsz /dev/nvme0n1
4096

This is the answer as to why when you ran it my way it was actually right by the way. That’s why. You’re massively cheating on the blocksize and that is not the correct blocksize for the filesystem.

So you’re testing a block size that is literally massive compared to the blocksize that it is actually formatted to. Why? Do you know? What are you even benchmarking if you aren’t even using the blocksize of the filesystem? It’s not the right way to do it. It’s a reflection of nothing whatsoever because that’s not your filesystem’s blocksize.

I’m stunned. They don’t increase the maximum PCIe rate. That’s exactly why your test to /dev/null was garbage. I thought this was what we were trying to teach *you* not me. It can’t and it isn’t. How do you think you got 400MB/s? Do you think that’s how fast it was going over the PCIe interface just because it said that? I thought we already explained and went through that it is an artificially inflated number.

DD does not measure the PCIe interface speed. It’s not that smart. It has no idea what optimizations and caching are being applied unless you specifically disable them (or request the right ones in the case of fsync). DD doesn’t have a magic sensor on the PCIe interface to measure the real speeds with. It just calculates it from the time of the operations and you, sir, have no clue what you are doing with your operations and that is *still* the issue.

This is bad, bad testing all around. I’m only replying again because you’re still not getting it and hopefully this cleared up the last few points of confusion here. The surety you had that you were right in both of these posts too and how wrong I was. Boy oh boy. The balls to do that and play the expert though after your /dev/null initial testing mistake I kind of respect though. That’s pretty much the most rookie mistake there is you can make with storage benchmarking in Linux. It’s literally storage benchmarking 101 material.

You still have yet to even *touch* a program actually *meant* to benchmark storage on Linux (such as iozone and fio). Not even touched. You are continuing to argue with me about improper use of a tool that is literally not meant to test storage performance to prove that I’m wrong about it performing at PCIe 1.0 speeds. You’re playing an expert and you haven’t even used a tool meant for storage benchmarking yet. It’s kind of ridiculous.

The sum result of all of the mistakes you made here only got it up to 280MB/s. That’s 30MB/s above the cap and you’re absolutely *certain* that it’s proof it’s PCIe 2.0 without running a single real benchmarking tool to the point where you told me straight up that I’m wrong. Twice. I’ve literally just shown you where your seeming extra speed was coming from (and explained / documented it).

If you want to see what PCIe 2.0 performance looks like you should see the pibenchmarks.com top scores page. Most of the top scores are using the Raspberry Pi Compute Module and the #1 score is using PCIe 3.0 (but it’s a x86_64 board, the ODROID H3 which I half considered disqualifying because of it being x86_64 but it is still a SBC).

The top Raspberry Pi scores are around 30,000. Surely we can all agree that the Raspberry Pi Compute Module does not have PCIe 3.0 yet it hits 30k and can easily exceed 250MB DD write routinely. This one hit 292MB/s.

You start seeing Radxa boards pretty soon after the top 10. We have a Radxa Rock 5B right here that got a score of 26,728. DD write? 463MB/s. THAT is what PCIe 2.0 performance looks like. It’s not just the Rock 5B though (which should theoretically have a PCIe 3.0 interface but there are *definitely* no benchmarks showing that level of performance either for the Rock 5B yet, only the ODROID H3 so far but I do have my own Rock 5B ordered). There’s a lot of Radxa models that can enable PCIe 2.0 and they’re all over the top page.

Guess what the highest score *ever* recorded on the Orange Pi 5 is? This one. 22,625. It’s down *thousands* of points from any PCIe 2.0 board. It’s not even close. DD write of 242 MB/s. PCIe 1.0. That’s the fastest.