The Orange Pi 5 has finally arrived! I received my pre-order and the board is great. So should you go out and buy it? Probably, but there are some things you should know first that you may not be expecting.
The biggest thing to know is that there is no WiFi/Bluetooth included. If you were planning on using Ethernet anyway this doesn’t have much of an impact. If you do need wireless capabilities we’ll cover what options are available.
In this review we’ll cover what you need to know about the Orange Pi 5 including it’s onboard capabilities, the available RAM options as well as benchmark the board. Let’s get started!
Hardware Used
Orange Pi 5
The Orange Pi 5 the latest release from Orange Pi and is the most powerful model yet. It has a 6 core CPU and options from 4GB of RAM all the way up to 32GB of RAM!
The Geekworm copper heatsink set is designed to fit many different single board computers. It uses thermal conductive adhesive which many “cheap” heatsink kits for SBCs don’t have. Eliminates hotspots and reduces throttling. Can be further enhanced by powered cooling over the heatsinks.
The Kioxia (Toshiba) 128GB M.2 2230 PCIe NVMe drive is much shorter than most NVMe drives (full size is 2280). It fits great with single board computers / tablets / other smaller form factors.
The Orange Pi monitor is meant to be a portable monitor you can take anywhere. It has a resolution of 1080P and features a hinge in the back that folds out to support the monitor.
The Orange Pi 5 official wireless module is designed to fit into a M-keyed M.2 slot (the only one the Orange Pi 5 has). This WiFi adapter will work with both Linux and Android.
HDMI2.1, up to 8K @60Hz DP1.4 (DisplayPort) DP 1.4 and USB 3.1 ports are multiplexed and the port is shared with Type-C 2 * MIPI D-PHY TX 4Lane Configurable up to 4K @60Hz
Camera
MIPI CSI 4Lane 2 * MIPI D-PHY RX 4Lane
Audio
CODEC: ES8388 3.5mm headphone jack audio input/output Input: Onboard MIC HDMI 2.1 eARC
Ethernet
10/100/1000Mbps Ethernet
Expansion Port
For extending UART, PWM, I2C, SPI, CAN and GPIO interfaces.
That is an outstanding score. We are getting NVMe performance. This score actually even beats my ODROID M1 benchmark.
The Orange Pi 5 is without a doubt a very powerful board and is performing exactly where it should be.
Keep in mind that this is PCIe 2.0 performance. This board does not have PCIe 3.0 (only the RK3588 proper has that, not the RK3588S).
UPDATE 1/2/2023: If you update the Orange Pi 5 firmware by using sudo orangepi-config and choosing “System->Firmware” and then choose to update the firmware I was able to get *low* PCIe 2.0 performance (about 280MB/s). I highly recommend updating the firmware with sudo orangepi-config. You may see some marginal improvements!
Due to this you should not use a powerful NVMe drive with the Orange Pi 5. You are limited in speeds to around 500MB/s at best (according to Orange Pi themselves via the user manual) and more like 250MB/s write according to the benchmarking.
I’ve now installed my heat sinks which looks like this:
Orange Pi 5 with Heat Sinks
That means it’s time for a head-to-head benchmarking match against the Pi 4 to see how the Orange Pi 5 compares. For the benchmark I used the “hardinfo” benchmark which can be installed on most Linux flavors with:
sudo apt install hardinfo
Here are the results:
Test
Orange Pi 5
Pi 4
CPU Blowfish (lower is better)
2.65s
5.24s
CPU CryptoHash (higher is better)
574.49 MiB/s
466.37 MiB/s
CPU Fibonacci (lower is better)
0.5s
1.73s
CPU N-Queens (lower is better)
4.24s
8.74s
CPU Zlib (higher is better)
0.80
0.31
FPU FFT (lower is better)
1.23s
5.52s
FPU Raytracing (lower is better)
2.86s
2.18s
GPU Drawing (higher is better)
2064.13 HiMarks
1708.15 HiMarks
That is almost a clean sweep for the Orange Pi 5! The only category it didn’t win was FPU raytracing interestingly enough. On GPU drawing performance however the Orange Pi 5 scored significantly higher and also won all other categories.
Pros / Cons
Pros
4 GB and 8 GB RAM variants cost under $100
M.2 slot supports high speed NVMe storage
RAM options from 4 GB all the way up to 32 GB available
Cons
No WiFi or Bluetooth included (requires either adapter for the M.2 slot or a USB adapter to get WiFi/Bluetooth capabilities)
No eMMC option
PCIe speeds are limited to 500MB/s (PCIe 2.0, benchmarks show closer to 250MB/s write or PCIe 1.0 performance) — this is slower than SATA3
Conclusion
The Orange Pi 5 feels almost perfect except for the lack of built in WiFi / Bluetooth. This seems like a surprising choice on what seems like is portrayed as their “flagship” model. Fortunately it is easy to add WiFi/Bluetooth on the board via either the custom M.2 wireless PCB or by using one of your USB ports and just using a USB-based WiFi/BT chip.
The board performs extremely well. The GPU is powerful on the board and feels very snappy while using the desktop OS and applications. This board would be a good choice for almost any use case. It would make a great Minecraft server as well.
I’d recommend this one for just about anyone. The price is right. There are widely varying amounts of RAM available depending on what you need. There are good Linux and Android images available even at launch. At under $100 for the 4 GB – 8 GB the Orange Pi 5 is priced well in this market especially for the power and flexibility it offers!
272 thoughts on “Orange Pi 5 Review – Powerful, No WiFi”
renaud
Thanks a lot for your precise responses. In the case of the OPi5, there is nothing hidden about the nvme speed : its’in the user manual, it’s explained the theroic speed is 500MB/s. That’s why I bought a 8$ nvme. Anyway et 350MB/s, it’s better than the SD Card.
I worked last week with the card prototyping some doker loki grafana promethus things and was happy with the speed and the debian. Nice little thing to test the deployment in arm64.
Now I think it’s OK for another one with more ram.
Absolutely, you planned accordingly here! My NVMe drive is also $8.99 right now that I used for this review. I honestly think this is the right way to go. I’m happy with my decision at almost exactly the same cost as you are.
Some people have tried throwing really powerful/expensive NVMe drives in there though and been disappointed from the results. You’re right though that it makes perfect sense when you understand the capabilities. We can wish it had PCIe 3.0 but this board is still a buy without it (especially in this market at these prices).
Hopefully the review will help some people realize this though so they don’t buy the board and end up unhappy as it’s not exactly advertised that it’s only PCIe 1.0 either (and it’s the cut down version of the RK3588 which does have PCIe 3.0). Given this it’s probably best to clear the air so people have the right expectations and make the right purchasing decisions and board decisions for their project / use case.
I want everyone to be as happy with it as we are so we needed to cover that as not everyone is going to dig through the manual/spec sheet for sure (nor is it always correct such as the CPU on there right now on the Wiki’s specifications page).
According to the manual the NVMe interface is PCIe 2.0×1, not PCIe 1.0 (that’s still capped at 500MB/s though). This is also confirmed by the RK3588S datasheet.
Okay, the fastest benchmark is literally half your 500MB/s number for even DD Write (an ideal bulk test, the random tests you’re nowhere even near 250). It’s supposed to be 500 for 2.0 and for PCIe 3.0 it’s supposed to be 1000. Does that look like 500 you to? This is literally the highest speed *ever* recorded on the device. These are PCIe 1.0 speeds.
So why is HDParm showing above 250 on some of these? Because HDParm uses all of your drive’s caching and other technologies available. That’s how they are getting over 250. Anything actually over 250 is thanks to their drive features such as caching and better performance storage controllers. Make no mistake though, it’s bottlenecked to hell and no cache/storage controller can make up for that much more than you’re seeing in that score. It’s using literally all of the storage caching and optimization technology we have on planet earth to get it that high (and it’s a pathetic result, on PC it would do 2-3x higher performance easily over the proper interfaces).
It’s not just a little less than PCIe 2.0 speeds. We aren’t hitting 400-450. We are hitting 250. We are *literally* hitting the PCIe 1.0 cap and are not even within 50% of the PCIe 2.0 cap.
If it is PCIe 2.0 it might as well be PCIe 1.0 because that is how it’s performing. Who knows what the bottleneck is internally. You aren’t getting any 500MB/s scores on this device though. Nobody has and nobody will because these are already better drives in some of these top end tests than I or most of you are probably using (or should use as I’ve covered, you should use a cheap drive).
I don’t see this making much of a difference anyway. Is there any such thing as a PCIe 1.0 or PCIe 2.0 drive? I’ve never seen one before. I thought that we were already on PCIe 3.0 before NVMe even existed. We definitely were by the time any consumers were buying them.
If this device had a SATA3 interface (like a real one instead of going over USB) it would literally be faster than the PCIe 1.0 interface in this device (or maybe 2.0 but the speeds disagree) because SATA3 is up to 750MB/s. Nobody should be defending a PCIe interface that is performing at less than half of the SATA3 rated speeds . That’s the sad thing too. PCIe 2.0 would be *SLOWER* than SATA 3 and we *ARE NOT EVEN* hitting PCIe 2.0 speeds.
You can verify what I’m saying by plugging your drive into a computer and running my storage benchmark on it. See what the drive can do on PC. You will go from 17k-20k to 50k-60k+. If this was a PCIe 2.0 interface your performance wouldn’t triple (or more) when going to PCIe 3.0 as that is only going from 500MB to 1000MB/s theoretically. The walls are 250, 500, and 1000MB/s respectively for 1.0, 2.0 and 3.0. This device is stuck at the 250 wall (the lowest, dramatically lower than even SATA3’s 750MB/s and half of PCIe 2.0’s supposed 500MB/s) no matter what you put in it.
It honestly doesn’t matter if this is deliberately mislabeled, an honest mistake or if it actually is PCIe 2.0. This might technically be a PCIe 2.0 interface. Does it matter though if you are stuck at the PCIe 1.0 wall at 250MB/s? Does it matter if it’s technically PCIe 2.0 if it can’t perform higher than a PCIe 1.0 device due to other bottlenecks or cuts? We have the numbers. Expect PCIe 1.0 performance numbers because we have already ran them and that’s what they are!
I am not disputing your benchmark results or defending anything, just correcting the specs.
But if the HDParm 367.21 MB/s result is indeed correct then it proves that the PCIe transfer rate is not limited to 250MB/s so it’s not PCIe 1.0 (it does not matter if the data comes from the drive itself or its cache, it still has to go through the PCIe bus). If one cannot get close to 500MB/s then the bottleneck must be somewhere else. It could still be poor PCIe implementation but not the fact that it is 1.0 vs 2.0.
I understand that but I’m actually disputing that it does matter. I’m saying it doesn’t matter. You are going to get 250MB/s maximum out of this device. That is PCIe 1.0 performance.
Maybe it’s technically PCIe 2.0. Okay. What does that do for you? Isn’t the whole point of that supposed to mean you can get 500MB/s (or at least higher than PCIe 1.0’s 250MB/s even if you nitpick about the theoretical maximum part)? You can’t. You can’t hit those numbers. You can barely hit the numbers for PCIe 1.0 (and only the fastest benchmarks in the world came close to actually hitting PCIe 1.0’s theoretical 250MB/s). Go ahead and try for us and show us your PCIe 2.0 performance numbers and I will apologize and say you are right.
I explained why HDParm can hit speeds above the maximum rated speeds. It’s due to caching and storage controller optimizations. It’s not really exceeding 250MB/s. It’s still stuck the same as DDWrite. The same thing happens on other devices. You can exceed the theoretical limits due to caching and other processes but it’s not “real”. Data was not traveling at those speeds over that interface. It’s only after calculating the caching and all of the other optimizations that the *effective* speed was that for the test.
This would be exactly why we benchmark it. I don’t understand why you’re making this technical distinction. Don’t give them credit for giving this a PCIe 2.0 interface when it can’t hit PCIe 2.0 rated speeds. That is a meaningless distinction and I won’t be joining you. No, this is a PCIe 1.0 250MB/s speed interface and if it’s supposed to be higher it’s broken/bottlenecked.
Honestly if we get another 20 benchmarks and not a single one of them has a DD write test that can exceed 250MB/s then I’d go even further and say they are *wrong* about it being PCIe 2.0 and not just that it’s bottlenecked/underperforming. If you look at the benchmarks closer you will see that the fastest ones are all dangerously flirting with 250MB/s. So dangerously that it looks like they’re bumping right up against the ceiling to me.
The HDParm scores are also exactly the amount *above* 250 that I would expect them to be with caching/storage controller optimizations. They’re also not nearly high enough to even qualify as PCIe 2.0 speeds. They look just like 250MB/s with optimizations/caching to me and not a single point higher than that would yield.
Again, we need more tests to confirm it for sure, but it sure looks like PCIe 1.0 actually for real to me (and if it’s not then it may as well be with these performance numbers).
My Orange Pi 5 finally arrived and I could test myself. I am getting 401 MB/s sustained with dd: root@orangepi5:~# sync
root@orangepi5:~# echo 3 > /proc/sys/vm/drop_caches
root@orangepi5:~# dd if=/dev/nvme0n1 of=/dev/null bs=1M status=progress
255749783552 bytes (256 GB, 238 GiB) copied, 638 s, 401 MB/s
244198+1 records in
244198+1 records out
256060514304 bytes (256 GB, 238 GiB) copied, 638.76 s, 401 MB/s
root@orangepi5:~#
Still not 500MB/s but definitely not limited to 250MB/s.
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:
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!
babacki
This is not how it works. dd is the process reading the data from one file (device) and writing to another. Writing do /dev/null is indeed cheating and the data is simply discarded. But this doesn’t matter. The input device (SSD) does not know what happens to the data and it has no choice but to actually read it and transmit it over the PCIe bus. Any drive cache/controller optimizations happen on the device side and can only affect the reading from the physical media but not the PCIe transfer rate.
Here is the proof: root@orangepi5:/tmp# dd if=/dev/nvme0n1 of=/tmp/foo bs=1M count=4096 status=progress
4114612224 bytes (4.1 GB, 3.8 GiB) copied, 11 s, 374 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 11.9653 s, 359 MB/s
root@orangepi5:/tmp#
This is similar as before but writing to a file in /tmp (which is on a ramdisk). Yes, it is slower than /dev/null because writing to a ramdisk is slower then discarding the data. But still much faster than 250 MB/s and your cheating theory does not apply.
And yes, writing to SSD is slower than reading: root@orangepi5:/tmp# dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=1024 conv=fdatasync status=progress
967835648 bytes (968 MB, 923 MiB) copied, 1 s, 967 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.83081 s, 280 MB/s
root@orangepi5:/tmp#
This is not unexpected as most SSDs (especially the very cheap ones like mine) are much slower at writes. But even this is still faster than the 250 MB/s PCIe 1.0 limit.
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?
babacki
Look, I tweaked things to remove as much overhead as possible (like Linux filesystem, small block size etc.). And yes, I did wipe the NVMe drive to do this test (I was booted from SD card for this) in order to not to go through the filesystem.
But these tweaks CANNOT artificially increase the MAXIMUM POSSIBLE PCIe transfer rate, which is what I am trying to test. Maybe this is the misunderstanding: I am not trying to test the real life drive performance or compare to other benchmarks. I am I just trying to determine if the PCIe transfer rate is limited to 250 MB/s like you claim (it’s not).
I did not post the results from your test because they are similar to yours (which I have no problem admitting) but they are not relevant for this purpose due to extra overhead.
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?
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.
I’m still waiting for this board to arrive so I can try it out. I’m already reading the manual.
First of all thank you for sharing the information about the orange pi 5.
I have seen the performance of the nvme pcie x1 ssd and I think it is not worth using this type of drive. Instead, I bet more on leaving the nvme connection free to adapt Wifi and bluetooth.
I would like you to test the performance of a SATA3 SSD on the USB 3.0 port. The speed should be very similar to what is achieved with the NVME SSD.
I think it would be possible to configure an image to start through the USB 3.0 port and thus be able to have good performance, large disk capacity and be cheap.
I will definitely do the first SATA3 test this morning. I definitely know it won’t be able to get much more than 8000-9000 points over USB 3.0 from many years of Raspberry Pi testing. The Orange Pi 5 has one USB 3.1 port though (something the Pi doesn’t have). Still, this should not be able to get anywhere near the NVMe scores. I would guess about half at around 8000-9000 points since that’s generally where the USB 3.0 bus gets maxed out but it might surprise us and put up a 5 figure score if the USB 3.1 is able to give it an edge here.
Traditionally I have always recommended against going NVMe over USB 3.0 for the exact reasoning you are saying. On the Pi 4 you would still hit the exact same ceiling with NVMe as you would with SATA3. Your scores would be identical. That won’t be the case here because PCIe (even 1.0) is just plain a lot faster than USB 3.0. NVMe will win but will it win by enough to justify the dramatically more expensive cost of a NVMe drive?
However, keep in mind my NVMe drive I used for my benchmark cost $10 on Amazon. Actually today it’s only $8.99. It’s a 128GB SSSTC OEM module. I spent less on it than most people will spend on their SD cards and the performance is something like 17-20x a SD card. The people with nicer NVMe drives beat my score (I was 17,718 and some people got as high as 19,641 so far with better drives). I bet those drives cost a lot more than $8.99 though and you can easily spend hundreds (or even thousands if you go real big with PCIe 4.0/5.0) on a good NVMe drive which is *definitely* not going to make sense to do when this device can only do PCIe 1.0.
Using a monster NVMe drive with PCIe 1.0 makes no sense though. Yes, my SSSTC only got 17k to some other people’s 19k scores. The reason it’s a silly comparison between these though is that both of them would score 50,000+ on a PC. They’re bottlenecked on PCIe 1.0. The only reason the nicer drives still score higher is because of things like higher quality onboard cache, better random read/write performance and other more subtle drive differences. They’re still both bottlenecked by PCIe 1.0 and the only reason we can tell any difference at all is due to quality differences in cache and the storage controller.
I’m guessing the answer will probably be yes it’s still worth it to use NVMe but you should use a cheap drive. Let’s do the actual testing though and find out for sure (and what the exact #s are).
I’ll test and post the SATA3 benchmark as a reply to this!
I have the results! So I wasn’t sure which port was the USB 3.1 port (the top or the bottom). Let us learn together and find out which port is the fastest (if either of them are):
Test #1 – 10,933 – Top USB port – Crucial MX200 – StarTech 2.5″ SATA to USB 3.1 adapter Test #2 – 2,392 – Bottom USB port – Crucial MX200 – StarTech 2.5″ SATA to USB 3.1 adapter
Well, those are fascinating! What did we find? First of all yes the USB 3.1 in this board does make a difference. You can’t get scores that high on the Pi 4 over USB 3.0. These are in fact USB 3.1 speeds.
We also found that oh my goodness HOLY CRAP do *NOT* use the bottom USB port. It dropped my score to 2,392. That’s damn near USB 2.0 performance. What?! Avoid bottom USB port! In fact it says it *IS* USB 2.0 but it’s not. It’s a blue port (the bottom of the two). The keyboard is plugged into my white USB 2.0 port (and was for both tests). I didn’t test the white USB port but I suppose it’s possible they put the wrong color tabs and that the white port is actually the USB 3.0 port the board is supposed to have? How strange.
The PCIe 1.0 interface is still roughly twice as fast (or a little less than twice as fast thanks to the USB 3.1 interface). These are very interesting results nonetheless though because now it’s a lot easier to make a calculation on whether using that NVMe drive is worth it.
It’s unquestionably not worth it to buy an extremely powerful PCIe 3.0/4.0/5.0 NVMe drive. Just get the cheapest M.2 NVMe drive you can find because you will be using PCIe 1.0 no matter what the drive can do.
I’d still maintain that the smartest choice is probably to get a super cheap NVMe drive and use a USB WiFi adapter if you needed WiFi capabilities (and put it in the bottom USB port where we now know the I/O speeds are terrible but are still more than fast enough for USB WiFi). This will give you the excellent 17-20k I/O performance scores for very cheap. Hopefully those help you decide what makes the most sense for you!
UPDATE: I had to know if the white USB port would perform well. I set out to perform a test #3 and to my surprise it won’t even boot off the white USB port.
These findings actually have some implications. You really only have one fast USB 3.1 port. The other port below it (despite being blue) either is or is performing at the level of USB 2.1. The white port is presumably actually USB 2.0 (at best, if it was 1.0 I’d assume it would be black but all bets are off at this point since we know the bottom blue one is not USB 3.0).
That is not a nice surprise at all. This means that you probably want to use a NVMe drive so you can keep your one fast USB-A 3.1 port open. If you definitely still want to USB boot or if you have a lot of devices you need to hook up at USB 3.0+ speeds I think you are going to need a USB hub with this device!
I also have a bunch of HP USB-C hubs that would turn the one USB-C port that is open (the one not being used for power) into a USB hub. HP gives these out for free with a lot of their laptops so I ended up with a pile of them while working as a tech from users who already had / didn’t want the one that came with their refreshed laptop. That might be a good solution for some people as well (look for cheaper ones than the HP one I linked, that’s just one I can personally vouch for / have tested for reference and surely there’s cheaper options).
I suppose it could be a kernel/driver issue (meaning maybe it could be fixed/improved) but for now plan accordingly as if this device had a single USB-A 3.1 port (and 2 USB 2.0 otherwise) as well as the open USB-C port.
Hello again.
Thanks for the tests.
Can you test with the usb-c port in the middle? I believe it supports data transfer and it is usb 3.1. See if you get a difference with the white usb port.
By the way I just bought the SSD for $8.99. As I live in Spain, transport and taxes are added and I ended up paying €22.
Of course! So I tried to test this and just like the white USB port it cannot boot from the USB-C port (even using the SD card as a bootloader). It never detects the drive or starts up.
The only ports that appear to support USB booting are the blue ones. The top one is fast and the bottom one is slow. I could not get my same drive to boot up though using either the USB-C port or the white port as the port the SSD was connected to! These ports of course work when the OS is started up still. It just doesn’t seem to want to check them during the boot process.
It’s kind of puzzling to me that I’m not able to boot off the white port or USB-C port. The reason I say that is that I’m already “cheating” and using a SD card as my boot loader anyway. It’s booting off my SD card then it’s just supposed to look for the right root partition to mount. What is interesting about these results is that the Orange Pi 5’s boot process appears to not even *look* at the white port or USB-C port during boot up. That would probably require modifying/rebuilding uboot or whatever bootloader they are using for the Orange Pi but it does not appear to check those places (even when bootstrapping with the SD card).
In other words the bootloader Orange Pi is using does not appear to be programmed to check the USB-C port or the white USB port during the boot process. It completely ignores them which is making my usual tricks such as using a SD card as the bootloader ineffective (as the bootloader isn’t looking on those ports for our root partition’s UUID, but it does check the blue ports).
I think this will work out well for you. The NVMe setup seems to leave you the most I/O options and I think this will end up being €22 well spent. The drive should serve you for years to come as I only expect more single board computers (and eventually the Pi itself) will have the same slot. It’s getting to the point where it’s hard to find a quality SD card cheaper than some of these NVMe drives are going for!
My 8 GB board is on its way and will hopefully arrive before Christmas. I’m trying to gather together everything that I need. Do you (or anyone else) have a recommendation for a WiFi/ Bluetooth dongle? I’d like to get one with both so I’m only using one port. I have several separate dongles but apparently this board is a bit picky. Thanks for your review. It has been helpful and I’m passing it on in other places.
Welcome, that’s such a great question. I desperately tried to find any reference to Orange Pi’s official wireless module for the Orange Pi 5 before publishing this but there’s not much out there yet.
I’ve only been able to see one place you can get it. It’s with this bundle on Amazon. They are offering the custom WiFi PCB with this bundle for some reason but I haven’t been able to find a standalone listing or even a reference to it. Look carefully at the Amazon options as you click through the different listings (there isn’t really a pic of the WiFi module) but you’ll see the description updating saying they’re including it in that one.
Okay, so what could you use alternatively? I gave this some thought before publishing and one idea I was thinking of recommending was using the ODROID USB WiFi adapter. Why? Because even though there are hundreds (maybe even thousands) of different USB WiFi adapters on Amazon including ones promising Linux compatibility I know the ODROID one basically will work plug and play with all SBCs and flavors of Linux I’ve tested it on. I know this one would work and I only didn’t include it in the article because it just seemed weird to recommend an ODROID-branded USB WiFi adapter on an Orange Pi article. This would be one safe bet though for sure (has Bluetooth but not BTLE). I also personally used this one to test to make sure it worked.
I have a few other ones like EDIMAX adapters but they’re all older models that are harder to find on Amazon. A pretty good test on whether they would work is to just plug them into a Raspberry Pi or another Orange Pi / ODROID. If it works with Debian / Ubuntu on those boards then it’s extremely likely that it will work fine with the Orange Pi 5 as well on their Ubuntu / Debian distro. The best ones to use will be using chipsets that are mainlined into the Linux kernel and don’t require any type of extra drivers to work (that’s how you get the plug and play at least, as well as it working on ARM without having to build a driver).
When people say it’s picky with the USB WiFi adapters I’d say that’s pretty true for Linux SBCs in general. A lot of the old ones that people expect to work plug and play with Linux on PCs haven’t traditionally always played nice with SBCs (or maybe when taken to ARM is a better way to put it). I’ve found though that if you find one that works well with one ARM-based single board computer using Debian/Ubuntu (as in you plug it in, Linux detects it and it just works) then this will generally remain true across the different competitor boards. It’s finding that initial compatible one that is tricky (because once you have one it usually will work with all of them).
You can generally google your adapter (or often the more important detail is the chipset inside your adapter like Realtek XXX, Atheros XXX, etc.) with “Linux mainline kernel support” and get an idea of whether it has mainline support. The reason this is so desirable is that if the driver code is in the Linux kernel then *all* versions of Linux newer than the version support was added in will support it (unless the person/organization compiling your kernel specifically disables support for them). Even more importantly though is that this also means it will support ARM and other architectures out of the box. If your Linux kernel works/builds for ARM and the code for your WiFi device is in the mainline Linux kernel then it will “just work”.
Hopefully we will see a standalone listing from Orange Pi for this as I don’t see one on their official store yet. I still can’t even find a picture of the additional module. Hopefully that helps give some ideas at least!
Thanks a lot.
It has become completely clear to me that there are two usb ports (white USB-A and the central USB-C) that are not checked at boot.
As you comment, it would be possible to boot with an SD and after boot if you have a copy of the system on a usb disk inserted in these ports, in which it is impossible to start the boot. Prepare the boot script to mount the partitions of those disks on the partitions of the SD.
Great question, absolutely! So this is actually exactly what I did. I did this for all 4 tests. I never did a straight SSD boot and always used a SD card even with the NVMe drive. I’m not sure if everyone is doing this but I just assumed that it wouldn’t naturally boot from SSD and used the SD card anyway.
If it does boot from SSD natively I haven’t tried that yet. I almost never expect it to work as very few devices have boot loaders that support doing this (ODROID and Raspberry Pi come to mind). I did use the SD card to try all of these for sure. Hopefully that helps!
Oh who knows what it’s supposed to be Bob. Check out the Orange Pi 5 Wiki page. At the top of the Wiki we’ve got:
Orange Pi 5 uses Rockchip RK3588S new generation 8-core 64-bit processor, quad-core A76+quad-core A55, with 8nm process design,
Nice. Okay let’s scroll down now to the specifications:
Rockchip RK3399 (28nm HKMG process)
Oh boy. That’s the one I posted from their official spec sheet. Now what does Linux say?
orangepi@orangepi5:~$ uname -a
Linux orangepi5 5.10.110-rockchip-rk3588 #1.0.2 SMP Fri Dec 9 14:54:26 CST 2022 aarch64 aarch64 aarch64 GNU/Linux
Wow, amazing, all 3 of them disagree! I really wouldn’t be so sure especially if you’re going off the official documentation (which I’ve shown does not match and is a mess). At the very least we know for sure it’s not a RK3399 despite the Orange Pi 5 Wiki page still stating that today (but only on the spec sheet and not within the Wiki article).
I mean I can see what probably happened here. There’s 2 CPU sections and the one at the top is wrong. It looks like they copy/pasted and didn’t delete all the previous rows or something but it’s a pretty big mistake to make on your official Wiki’s spec sheet and it’s not the first time I’ve seen it. Whoever publishes and maintains these has a tendency to do this over there.
I’ve updated it to say RK3588S based on what Linux says (even though there’s no indication of an S within Linux but this isn’t necessarily unusual). Whatever the marketing monikers on this processor were meant to be Orange Pi blew it when they gave the wrong CPU entirely in their official Wiki’s specifications sheet (still listed today wrong). Is it the S or is it a RK3399, or is it a plain RK3588 as Linux is suggesting? Again, who cares, you cannot trust these spec sheets and we need to test it.
If you wanted to find this out definitively you would probably need to put the CPU under a scope and find something to definitively identify it (or use some sort of RockChip proprietary tool to positively identify it including the smaller details about whether it’s really a S vs. non S and things like that).
This is why I just bench it and let the numbers stand for themselves (I never believe them anyways and always test them no matter what because they do this all the time). The RockChip naming/identification is obviously quite confusing as even their own partners can’t keep these straight. Even when you can keep them straight the purpose of these names is marketing. We really just need to look at the numbers vs. something like the Pi 4 like I’ve done here to get meaningful comparisons and leave their confusing/contradictory marketing aside.
You obviously can’t take Orange Pi’s official documentation’s word for it (which is why we benchmark it in the first place, it doesn’t matter what they say it is nor can they make up their mind)! This is not the first time Orange Pi has gave out the wrong specifications on their spec sheet. The Orange Pi i96 and other models I’ve been personally involved with routinely have these wrong on the spec sheets (sometimes for the entire lifetime of the product).
Thanks for pointing this out as it gives me a chance to explain this issue which I didn’t really cover in the review. Yeah, the official documentation doesn’t match (even with itself against other parts of the documentation) and it’s a common problem with Orange Pi unfortunately! They can’t hide from the benchmarks though as putting the wrong CPU on a spec sheet will not make it score higher when we get the board in hand and test it! In this case the wrong CPU listed in the spec sheet is actually slower so they aren’t trying to make themselves look better here (and instead are making it look weaker so I’d say it’s definitely unintentional).
Nope. This is actually less information than uname -a as far as determining the SoC package. There is no RK3588S anywhere in /proc/cpuinfo or lscpu (or lshw). You’d need to have some sort of database or part listing for all of these part numbers and manufacturer codes. It doesn’t even know how to turn 0x41 into RockChip. It doesn’t recognize them like it would Intel or AMD etc.
The things people take for granted in x86_64 like the CPU names being fully fleshed out with Intel, AMD and all of the information in there is not a thing on ARM (or RISC-V either). Linux knows only the basics it’s showing in those commands and cannot at all identify whether it’s a RK3358S or the SoC package unfortunately!
This is why I said to positively identify this you’d probably put it under a scope or run a proprietary utility. I guess having a proprietary list of all of the manufacturer part codes and matching them up manually would be another way to confirm it manually. There’s no magic hardware database where Linux just knows all of these parts though. I don’t know why you think this stuff would be in there.
There is a hardware identification database on Linux but it only gets additions if companies submit requests for it (or the people using the software do). It’s pretty limited and will almost never know what cutting edge stuff is. For that to happen the manufacturers would have had to submit the device IDs and what they are way before the product was released and the truth is most manufacturers never submit this stuff at all.
Not only that, often manufacturers go to extreme lengths to keep that information top secret through things like nondisclosure agreements and that is not how Linux works (which is why it will just show generic stuff for many of these). It will just show up as the type of ARM CPU it is and that’s about as far as I’ve ever seen for most of these.
Have you seen the articles before new GPUs launch where someone will benchmark an unreleased GPU? It doesn’t show up in the benchmark sites as the new GPU name. NVIDIA and ATI go to great lengths to keep these secret and even use codenames when preparing device IDs for their products. This should be something a lot of people who follow tech hardware news probably have seen before. The people who did the benchmark are violating their NDAs even having that limited set of information hit the internet (and you better believe NVIDIA and ATI investigate them).
It’s literally a media-wide speculation game sometimes when these unknown hardware IDs are spotted on benchmarking sites putting up blazing scores on what these could be. It’s only when it gets closer to launch that NVIDIA and ATI will update their device ID reservations (with Microsoft and with Linux and Mac OS as well) to where in the OS it will show up as the right device. That is a Windows and Linux process thing though and it’s not baked into the hardware. It takes time and resources for that to happen and a lot of companies do not ever submit their hardware or even go through this process at all. Many more will only do it for Windows and never submit them for Linux.
It’s showing you everything it knows (and it’s not much, just some manufacturer IDs and product IDs that Linux has no idea how to turn into human readable form and would only be useful with a list from the manufacturer).
I mean even on Windows it doesn’t magically know what all the hardware is. If you don’t have the driver it shows up as “unidentified device” and gives a similar product ID, manufacturer ID etc. that means nothing if Windows has no driver/database to turn that into useful information. You’d actually see the same information in Windows if Windows could run on these. You’d see the exact same IDs and it would have no idea what they mean unless you have a compatible driver for it.
It’s purely a luxury that you’re ever able to get away with this on any platform. It means the hardware you’re using is mainstreamed (or old) enough that it’s made it’s way into the hardware identification databases built into Linux. Either that or a manufacturer is providing a driver that is providing that information. These fields are almost *never* populated on ARM or RISC-V that I’ve seen. It’s always just going to be 0x41 hex codes that are only useful if you’re already using some other list from somewhere else anyway.
The only reason uname -a is even helping is because RK3588 is built into the kernel name. That was done by Orange Pi themselves. Given that Orange Pi are the ones that have the wrong CPU posted in multiple places I would say that them typing that in as the name for the kernel is also not a confirmation of what this CPU really is. None of the tests you mentioned (or even my expanded ones I mentioned) can even resolve the name “RockChip”. They can’t even identify the manufacturer let alone the SoC package.
If you want to be sure as in 100% (like for real) it either goes under a scope or you match it against a proprietary manufacturer list (or using their identification utility). This has always been true and it’s also true on PC if you want to be 100% sure. Intel and AMD both have their own hardware identification and validation utilities as does RockChip (even for Linux although I’m not sure if there are apt packages available in the Orange Pi repositories or if you’d need to manually download/build them).
There are also third party utilities like CPU-Z you can use to identify and validate the hardware on Windows. Your choices are fewer on Linux (and I’d be surprised if they identified a lot of these RockChip ones) but there are some out there. This is an exact example of this. CPU-Z only works because the developers maintain a list of what the hardware is. All of them do. It’s why they have to constantly be updated to stay useful as they do not just know what this stuff is.
There is a very limited set of information that is actually coded into the hardware itself (the hexadecimal device IDs, manufacturer IDs, device type, etc.). You can figure out what it is from this *if* you have a good list (which is how CPU-Z and similar applications work). They are only as good as the list though. If you try running a 5 year old copy of CPU-Z on a modern system built within the last year for example you can see this in action!
I received my today as well and loaded it with Android 12, then loaded 3DMark. I received ‘4454’ which is very good. I did add small heatsink on the RK3588 and the smaller chip next to it. I ran the test several times with the same results. This is exactly what I was hoping for, but agree that not adding WIFI/BT was a misstep. I do have a couple of WIFI dongles that have worked with Wintel PCs as well as couple of Raspberry Pis, but sadly they are not being recognized by Android 12. I will have to investigate why, but at least my 10′ 1080P touchscreen works like a charm. Final goal is to create $200 Android/Cloud gamepad that I am currently using with the very, very limited NVIDIA Shield TV 2019 taking out of its shell. 8GB, 128GB NVME SSD and the Mali-G610 runs circles around the Shield. Can’t wait to see what the Orange Pi OS brings to the table and as James mentioned the NVMEs are super cheap (I bought 2) so I will just flash different OS builds and swap them out. Can’t wait to try out Armbain soon as it comes out as well. Really happy with my $84 early stocking stuffer 🙂
Great results and findings! Those are very interesting results with the USB WiFi adapters. I would have assumed the exact same thing as you (that most of these would have worked plug and play). In fact I believe if you tried in Linux this would almost certainly be the case (and it sounds like you’ve used some of them with the Pi before which would further confirm that). Definitely let us know if you find a good way to address this in Android. I’m definitely not as strong with Android as I am with Linux but I’m always trying to learn / discover more.
I’m very excited for this build. I think the Orange Pi 5 sounds perfect for it honestly and you’re getting quite a bit more firepower. I’m also looking forward to an Armbian release. Armbian always does such a great job and it will be very nice to have the nand_sata_install script that is included with Armbian. That should let people directly image the SSD from Armbian booted up on a SD card for example as setting up NVMe booting can be a bit tricky manually. It’s definitely a lot easier / faster to get a NVMe drive imaged with the convenience scripts.
Thanks for sharing, what a great $84 early stocking stuffer! It’s amazing this board is < $100 for what we're getting. Enjoy and take care!
Sadly the weather has delayed the two USB WIFI dongle variants. One looks like it might be lost :(. I am being lazy though instead of downloading there Android source code and seeing what it compatible.
I just received WaveShare’s new 8″ IPS 1280P screen with speaker drivers which highlighted another misstep by OrangePi and that is the mounting holes. Not sure why, even if the board is a little bigger, why they couldn’t make the mounting holes the same. So many screens and cases would still accommodate this board otherwise. I guess I can create and 3D print a plastic shim with threaded mounts to attach the OrangePi and after bolting it the standard RaspberryPi mounts keeping it as think as possible to ensure clearance.
FYI There is also company who is making 8″ tablet with 8 or 16GB and 128 or 256GB storage (plus SD card) for about $250. Still in the production phase, but moving forward with a sample. This could make for interesting competition to the Razer Android gamepad coming out 2023.
Welcome back! That is not good news that the weather has delayed the USB WiFi dongles! We’re definitely having the “bomb cyclone” in the US which has frozen out nearly half the country so a lot of people are likely in the same boat. We got skipped for Utah for this storm fortunately but we have ones moving in for later this week.
That’s an interesting idea to make a 3D printed plastic shim with threaded mounts to attach this. If you do this share the design/file here if you wouldn’t mind (we did have one 3D printed case design shared here). That sounds incredibly cool and useful.
Definitely let me know if you learn more details about the 8″ tablet Android gamepad competitor as I’d be curious to investigate this as well!
Yes, there is a very good reason I didn’t do this yet. I’m still waiting for a heat sink for it. It would not be fair to do CPU testing with the bare chip as it will throttle you back way, way more (and faster) than it will with a good heat sink on it. The temps get very “spiky” running bare as there’s nowhere for the heat to go but to the air directly from the chip (instead of the heat sink serving as an intermediary and also increasing the surface area).
I have a kit of 100pcs of various copper heat sink sizes coming (meant to fit just about any SBC chip) to avoid this problem in the future. It was supposed to beat the Orange Pi 5 here but it didn’t. I’m looking at the tracking # and it says it cleared customs on November 20th and USPS has been waiting for it since November 22nd. Ugh. That package is probably lost or something. I just ordered a couple of small kits from Amazon that says they’ll come on the 16th and I’ll contact Geekworm about my larger kit that is stuck.
It’s supposed to technically run okay without the heat sink according to Orange Pi (and it did for my initial testing and I/O benchmarking). Running fine though and achieving maximum performance / benchmarking are not the same thing and doing this type of testing directly on the CPU without the heat sink would be misleading. Anyone interested in the CPU benchmarks is not going to run it bare (myself included) since we can be 100% certain that it will not perform as well bare as it will with a $2 part on it to dissipate heat.
They definitely aren’t claiming that it won’t throttle less with a good heat sink on it (it will). Raspberry Pi says the same thing about the Pi technically not requiring the heat sink and everyone knows it’s not a good idea to run those without a heat sink and that throttling comes into play more without one (just like any silicon-based electronics basically, which is an advancement from when they used to literally fry themselves before throttling was widely implemented as a safety feature to prevent the temperature from ever getting to a critical point).
I will update and add these to the review as soon as I get my heat sink for it!
It’s not a RK3588. It’s a RK3588S. This is important because the RK3588 has PCIe 3.0 and the RK3588S has PCIe 3.0 removed (very unfortunate). It’s the cut down “light” version.
You may want to refer to these scores here. GadgetVersus has a better breakdown than the cpubenchmarks web site. The scores are pretty identical for CPU performance since it was features that were cut and not the number of cores or frequency. That’s a pretty great resource since it has not only the RK3588S (the real one) but a lot of comparable models making it easier to see the differences between these.
The most notable changes are the removal of the PCIe 3.0 interface, the addition of three CAN bus, and a smaller number of video output/input, Ethernet, USB, and PIPE PHY interfaces.
Man, I really wish we had got the PCIe 3.0 interface. Someone actually mentioned to me on Twitter that they were a little disappointed by the top-end NVMe scores. It’s because the PCIe 3.0 interface got cut so it has to fall back to lower versions (PCIe 1 according to GadgetVersus above). I definitely second their disappointment because so many single board computers that have PCIe capabilities don’t have PCIe 3.0 (it’s more expensive to include). The Orange Pi 5 would have stood out even more if this had made it in and we didn’t get the cut down version.
This is why I disagree with the whole “CPU benchmarks are more interesting” thing here. Not really. You’re being misled by CPU benchmarks as those will not tell you that the PCIe 3.0 interface was cut on this device. The CPU benchmarks are identical between these. Are they the same though? No. You’d miss it without I/O benchmarking which is exactly why I do it.
I/O benchmarking is generally testing how fast we can write to your storage device. It’s my primary method because you cannot hide bottlenecks from I/O testing. For you to get maximum I/O testing scores you cannot have a cheap/bad CPU, cannot have cheap memory, can’t cut down the core/bus speeds and you can’t cheap out on PCIe lanes. All of the tricks they do to fool people with things like pure CPU performance testing won’t work. Everything needs to be working well *together* in the right proportions for I/O benchmarking to come out correct.
This is *especially* something to watch out for on single board computers. They have to cut corners to try to get anywhere near the Pi on pricing. The manufacturers know how to do it without it showing up in the benchmarking scores that the majority of people are looking at. This is the Orange Pi *5*. They’ve been doing this for a long time and they’ve survived in a market where many competitors haven’t.
It’s hardly unique to single board computers though. The manufacturers have been doing this with CPU/GPU testing *forever*. They plan their launches around some of these benchmark numbers. They’re very aware of all the price/performance ratio lingo and they calculate/plan it each generation. They’re also notorious for cutting down on things like memory bus bandwidth and other metrics that most consumers don’t look at. But these of course do matter. They know most people won’t notice those cuts though whereas if they dropped the clock speed of the device by even 50MHz this would have a devastating backlash vs. cutting the memory bus width.
There are a lot of ways to play games with these numbers when you know that a certain # of consumers will *only* look at the top CPU performance benchmark score and literally nothing else. Don’t be that consumer (for your own sake and everyone else’s sake don’t reward this behavior). It does matter if your devices will only work over PCIe 1.0 even though this won’t change the CPU overall performance score on cpubenchmarks a single point.
I’d really encourage people to understand that the manufacturers know all of your lingo. They know the benchmarks you favor. They know your weaknesses and they’re exploiting them. Their marketing department is counting on it and you have to evolve and start using more comprehensive benchmarks if you don’t want to fall victim to this. Make them plan a product that delivers good performance all around and not on very specific metrics. They are very comfortable with cpubenchmarks and all of these narrow ones that have been around forever (which is exactly why you shouldn’t be).
The people absolutely obsessing over this cpubenchmarks score are literally playing right into their hands. The product design decisions such as cutting to the RK3588S is designed to trick people *exactly like you* and they’ve been doing it for multiple board generations. The manufacturers know the very narrow range of benchmarks they can’t touch because it’s all you’re looking at and then everything else gets cut and you think you’re buying some god-tier board. These consumers won’t change in an industry defined by change and it’s sad because people like this think they’re doing their research.
Your research needs to evolve just like the manufacturer’s techniques to trick you evolved. It’s not smart to look at benchmarks the way we did 15-20 years ago (which is how I view what you’re doing here). We literally know better now but some people didn’t keep up. If you are doing something the same way in IT that you did 10-20 years ago then it’s because you’re comfortable and have fallen behind.
The game has changed. Sure, the people who don’t look at benchmarks at all are still completely uninformed consumers. Unfortunately that doesn’t make the people looking at pure GPU and CPU benchmarks the informed consumers. No, those are the misinformed/misled consumers that have fallen for the very targeted design decisions made so that those people do not spot any of the product’s real flaws. The informed consumers are using more comprehensive benchmarking than this in the 2020s.
At any rate there are some other benchmarks as well to check out and the scores are pretty similar (about 6133). It also remains an amazing value and top recommended board at least from me. The benchmarks have done nothing but solidify that in my mind!
I’m not saying it’s perfect though and in fact I’m saying you should probably be aware that the PCIe 3.0 interface was cut limiting your NVMe performance score potential as for certain people that may really have an impact on what they wanted to do with the board such is if someone wanted to invest in a 4TB NVMe high performance drive to make some kind of storage server. You’d want to buy a more expensive board for that use case but if you’re comparing it against the Pi then obviously the Pi doesn’t have any of that stuff either (and performs slower on every benchmark save FPU raytracing).
Thanks a lot for your precise responses. In the case of the OPi5, there is nothing hidden about the nvme speed : its’in the user manual, it’s explained the theroic speed is 500MB/s. That’s why I bought a 8$ nvme. Anyway et 350MB/s, it’s better than the SD Card.
I worked last week with the card prototyping some doker loki grafana promethus things and was happy with the speed and the debian. Nice little thing to test the deployment in arm64.
Now I think it’s OK for another one with more ram.
Hey renaud,
Absolutely, you planned accordingly here! My NVMe drive is also $8.99 right now that I used for this review. I honestly think this is the right way to go. I’m happy with my decision at almost exactly the same cost as you are.
Some people have tried throwing really powerful/expensive NVMe drives in there though and been disappointed from the results. You’re right though that it makes perfect sense when you understand the capabilities. We can wish it had PCIe 3.0 but this board is still a buy without it (especially in this market at these prices).
Hopefully the review will help some people realize this though so they don’t buy the board and end up unhappy as it’s not exactly advertised that it’s only PCIe 1.0 either (and it’s the cut down version of the RK3588 which does have PCIe 3.0). Given this it’s probably best to clear the air so people have the right expectations and make the right purchasing decisions and board decisions for their project / use case.
I want everyone to be as happy with it as we are so we needed to cover that as not everyone is going to dig through the manual/spec sheet for sure (nor is it always correct such as the CPU on there right now on the Wiki’s specifications page).
Enjoy and take care!
According to the manual the NVMe interface is PCIe 2.0×1, not PCIe 1.0 (that’s still capped at 500MB/s though). This is also confirmed by the RK3588S datasheet.
Hey babacki,
Nobody is getting anywhere near 500MB/s. This is the fastest benchmark anyone has ever recorded for the Orange Pi 5 (19,641):
DD Write - 234 MB/sHDParm - 367.21 MB/s
Okay, the fastest benchmark is literally half your 500MB/s number for even DD Write (an ideal bulk test, the random tests you’re nowhere even near 250). It’s supposed to be 500 for 2.0 and for PCIe 3.0 it’s supposed to be 1000. Does that look like 500 you to? This is literally the highest speed *ever* recorded on the device. These are PCIe 1.0 speeds.
So why is HDParm showing above 250 on some of these? Because HDParm uses all of your drive’s caching and other technologies available. That’s how they are getting over 250. Anything actually over 250 is thanks to their drive features such as caching and better performance storage controllers. Make no mistake though, it’s bottlenecked to hell and no cache/storage controller can make up for that much more than you’re seeing in that score. It’s using literally all of the storage caching and optimization technology we have on planet earth to get it that high (and it’s a pathetic result, on PC it would do 2-3x higher performance easily over the proper interfaces).
It’s not just a little less than PCIe 2.0 speeds. We aren’t hitting 400-450. We are hitting 250. We are *literally* hitting the PCIe 1.0 cap and are not even within 50% of the PCIe 2.0 cap.
If it is PCIe 2.0 it might as well be PCIe 1.0 because that is how it’s performing. Who knows what the bottleneck is internally. You aren’t getting any 500MB/s scores on this device though. Nobody has and nobody will because these are already better drives in some of these top end tests than I or most of you are probably using (or should use as I’ve covered, you should use a cheap drive).
I don’t see this making much of a difference anyway. Is there any such thing as a PCIe 1.0 or PCIe 2.0 drive? I’ve never seen one before. I thought that we were already on PCIe 3.0 before NVMe even existed. We definitely were by the time any consumers were buying them.
If this device had a SATA3 interface (like a real one instead of going over USB) it would literally be faster than the PCIe 1.0 interface in this device (or maybe 2.0 but the speeds disagree) because SATA3 is up to 750MB/s. Nobody should be defending a PCIe interface that is performing at less than half of the SATA3 rated speeds . That’s the sad thing too. PCIe 2.0 would be *SLOWER* than SATA 3 and we *ARE NOT EVEN* hitting PCIe 2.0 speeds.
You can verify what I’m saying by plugging your drive into a computer and running my storage benchmark on it. See what the drive can do on PC. You will go from 17k-20k to 50k-60k+. If this was a PCIe 2.0 interface your performance wouldn’t triple (or more) when going to PCIe 3.0 as that is only going from 500MB to 1000MB/s theoretically. The walls are 250, 500, and 1000MB/s respectively for 1.0, 2.0 and 3.0. This device is stuck at the 250 wall (the lowest, dramatically lower than even SATA3’s 750MB/s and half of PCIe 2.0’s supposed 500MB/s) no matter what you put in it.
It honestly doesn’t matter if this is deliberately mislabeled, an honest mistake or if it actually is PCIe 2.0. This might technically be a PCIe 2.0 interface. Does it matter though if you are stuck at the PCIe 1.0 wall at 250MB/s? Does it matter if it’s technically PCIe 2.0 if it can’t perform higher than a PCIe 1.0 device due to other bottlenecks or cuts? We have the numbers. Expect PCIe 1.0 performance numbers because we have already ran them and that’s what they are!
I am not disputing your benchmark results or defending anything, just correcting the specs.
But if the HDParm 367.21 MB/s result is indeed correct then it proves that the PCIe transfer rate is not limited to 250MB/s so it’s not PCIe 1.0 (it does not matter if the data comes from the drive itself or its cache, it still has to go through the PCIe bus). If one cannot get close to 500MB/s then the bottleneck must be somewhere else. It could still be poor PCIe implementation but not the fact that it is 1.0 vs 2.0.
Hey babacki,
I understand that but I’m actually disputing that it does matter. I’m saying it doesn’t matter. You are going to get 250MB/s maximum out of this device. That is PCIe 1.0 performance.
Maybe it’s technically PCIe 2.0. Okay. What does that do for you? Isn’t the whole point of that supposed to mean you can get 500MB/s (or at least higher than PCIe 1.0’s 250MB/s even if you nitpick about the theoretical maximum part)? You can’t. You can’t hit those numbers. You can barely hit the numbers for PCIe 1.0 (and only the fastest benchmarks in the world came close to actually hitting PCIe 1.0’s theoretical 250MB/s). Go ahead and try for us and show us your PCIe 2.0 performance numbers and I will apologize and say you are right.
I explained why HDParm can hit speeds above the maximum rated speeds. It’s due to caching and storage controller optimizations. It’s not really exceeding 250MB/s. It’s still stuck the same as DDWrite. The same thing happens on other devices. You can exceed the theoretical limits due to caching and other processes but it’s not “real”. Data was not traveling at those speeds over that interface. It’s only after calculating the caching and all of the other optimizations that the *effective* speed was that for the test.
This would be exactly why we benchmark it. I don’t understand why you’re making this technical distinction. Don’t give them credit for giving this a PCIe 2.0 interface when it can’t hit PCIe 2.0 rated speeds. That is a meaningless distinction and I won’t be joining you. No, this is a PCIe 1.0 250MB/s speed interface and if it’s supposed to be higher it’s broken/bottlenecked.
Honestly if we get another 20 benchmarks and not a single one of them has a DD write test that can exceed 250MB/s then I’d go even further and say they are *wrong* about it being PCIe 2.0 and not just that it’s bottlenecked/underperforming. If you look at the benchmarks closer you will see that the fastest ones are all dangerously flirting with 250MB/s. So dangerously that it looks like they’re bumping right up against the ceiling to me.
The HDParm scores are also exactly the amount *above* 250 that I would expect them to be with caching/storage controller optimizations. They’re also not nearly high enough to even qualify as PCIe 2.0 speeds. They look just like 250MB/s with optimizations/caching to me and not a single point higher than that would yield.
Again, we need more tests to confirm it for sure, but it sure looks like PCIe 1.0 actually for real to me (and if it’s not then it may as well be with these performance numbers).
My Orange Pi 5 finally arrived and I could test myself. I am getting 401 MB/s sustained with dd:
root@orangepi5:~# syncroot@orangepi5:~# echo 3 > /proc/sys/vm/drop_caches
root@orangepi5:~# dd if=/dev/nvme0n1 of=/dev/null bs=1M status=progress
255749783552 bytes (256 GB, 238 GiB) copied, 638 s, 401 MB/s
244198+1 records in
244198+1 records out
256060514304 bytes (256 GB, 238 GiB) copied, 638.76 s, 401 MB/s
root@orangepi5:~#
Still not 500MB/s but definitely not limited to 250MB/s.
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 bashOr alternatively can you do a proper DD write test like this:
dd if=/dev/zero of=test bs=4k count=80k conv=fsyncThis 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!
This is not how it works.
ddis the process reading the data from one file (device) and writing to another. Writing do/dev/nullis indeed cheating and the data is simply discarded. But this doesn’t matter. The input device (SSD) does not know what happens to the data and it has no choice but to actually read it and transmit it over the PCIe bus. Any drive cache/controller optimizations happen on the device side and can only affect the reading from the physical media but not the PCIe transfer rate.Here is the proof:
root@orangepi5:/tmp# dd if=/dev/nvme0n1 of=/tmp/foo bs=1M count=4096 status=progress4114612224 bytes (4.1 GB, 3.8 GiB) copied, 11 s, 374 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 11.9653 s, 359 MB/s
root@orangepi5:/tmp#
This is similar as before but writing to a file in /tmp (which is on a ramdisk). Yes, it is slower than /dev/null because writing to a ramdisk is slower then discarding the data. But still much faster than 250 MB/s and your cheating theory does not apply.
And yes, writing to SSD is slower than reading:
root@orangepi5:/tmp# dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=1024 conv=fdatasync status=progress967835648 bytes (968 MB, 923 MiB) copied, 1 s, 967 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.83081 s, 280 MB/s
root@orangepi5:/tmp#
This is not unexpected as most SSDs (especially the very cheap ones like mine) are much slower at writes. But even this is still faster than the 250 MB/s PCIe 1.0 limit.
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/nvme0n1Nice, 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?
Look, I tweaked things to remove as much overhead as possible (like Linux filesystem, small block size etc.). And yes, I did wipe the NVMe drive to do this test (I was booted from SD card for this) in order to not to go through the filesystem.
But these tweaks CANNOT artificially increase the MAXIMUM POSSIBLE PCIe transfer rate, which is what I am trying to test. Maybe this is the misunderstanding: I am not trying to test the real life drive performance or compare to other benchmarks. I am I just trying to determine if the PCIe transfer rate is limited to 250 MB/s like you claim (it’s not).
I did not post the results from your test because they are similar to yours (which I have no problem admitting) but they are not relevant for this purpose due to extra overhead.
Hey babacki,
Which ones should we start with? Why did you choose
conv=fdatasyncfor your test? That’s an interesting choice. Do you know what it does?fdatasync - physically write output file data before finishingfsync - 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/nvme0n14096
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.
Hello James A. Chambers.
I’m still waiting for this board to arrive so I can try it out. I’m already reading the manual.
First of all thank you for sharing the information about the orange pi 5.
I have seen the performance of the nvme pcie x1 ssd and I think it is not worth using this type of drive. Instead, I bet more on leaving the nvme connection free to adapt Wifi and bluetooth.
I would like you to test the performance of a SATA3 SSD on the USB 3.0 port. The speed should be very similar to what is achieved with the NVME SSD.
I think it would be possible to configure an image to start through the USB 3.0 port and thus be able to have good performance, large disk capacity and be cheap.
Greetings from Spain.
Hey Jesús Vega,
Welcome! This is actually a great way to think about this issue. So far there are 9 benchmarks for the Orange Pi 5 on Pi Benchmarks. Nobody has tried yet with a SATA3 drive yet though!
I will definitely do the first SATA3 test this morning. I definitely know it won’t be able to get much more than 8000-9000 points over USB 3.0 from many years of Raspberry Pi testing. The Orange Pi 5 has one USB 3.1 port though (something the Pi doesn’t have). Still, this should not be able to get anywhere near the NVMe scores. I would guess about half at around 8000-9000 points since that’s generally where the USB 3.0 bus gets maxed out but it might surprise us and put up a 5 figure score if the USB 3.1 is able to give it an edge here.
Traditionally I have always recommended against going NVMe over USB 3.0 for the exact reasoning you are saying. On the Pi 4 you would still hit the exact same ceiling with NVMe as you would with SATA3. Your scores would be identical. That won’t be the case here because PCIe (even 1.0) is just plain a lot faster than USB 3.0. NVMe will win but will it win by enough to justify the dramatically more expensive cost of a NVMe drive?
However, keep in mind my NVMe drive I used for my benchmark cost $10 on Amazon. Actually today it’s only $8.99. It’s a 128GB SSSTC OEM module. I spent less on it than most people will spend on their SD cards and the performance is something like 17-20x a SD card. The people with nicer NVMe drives beat my score (I was 17,718 and some people got as high as 19,641 so far with better drives). I bet those drives cost a lot more than $8.99 though and you can easily spend hundreds (or even thousands if you go real big with PCIe 4.0/5.0) on a good NVMe drive which is *definitely* not going to make sense to do when this device can only do PCIe 1.0.
Using a monster NVMe drive with PCIe 1.0 makes no sense though. Yes, my SSSTC only got 17k to some other people’s 19k scores. The reason it’s a silly comparison between these though is that both of them would score 50,000+ on a PC. They’re bottlenecked on PCIe 1.0. The only reason the nicer drives still score higher is because of things like higher quality onboard cache, better random read/write performance and other more subtle drive differences. They’re still both bottlenecked by PCIe 1.0 and the only reason we can tell any difference at all is due to quality differences in cache and the storage controller.
I’m guessing the answer will probably be yes it’s still worth it to use NVMe but you should use a cheap drive. Let’s do the actual testing though and find out for sure (and what the exact #s are).
I’ll test and post the SATA3 benchmark as a reply to this!
I have the results! So I wasn’t sure which port was the USB 3.1 port (the top or the bottom). Let us learn together and find out which port is the fastest (if either of them are):
Test #1 – 10,933 – Top USB port – Crucial MX200 – StarTech 2.5″ SATA to USB 3.1 adapter
Test #2 – 2,392 – Bottom USB port – Crucial MX200 – StarTech 2.5″ SATA to USB 3.1 adapter
Well, those are fascinating! What did we find? First of all yes the USB 3.1 in this board does make a difference. You can’t get scores that high on the Pi 4 over USB 3.0. These are in fact USB 3.1 speeds.
We also found that oh my goodness HOLY CRAP do *NOT* use the bottom USB port. It dropped my score to 2,392. That’s damn near USB 2.0 performance. What?! Avoid bottom USB port! In fact it says it *IS* USB 2.0 but it’s not. It’s a blue port (the bottom of the two). The keyboard is plugged into my white USB 2.0 port (and was for both tests). I didn’t test the white USB port but I suppose it’s possible they put the wrong color tabs and that the white port is actually the USB 3.0 port the board is supposed to have? How strange.
The PCIe 1.0 interface is still roughly twice as fast (or a little less than twice as fast thanks to the USB 3.1 interface). These are very interesting results nonetheless though because now it’s a lot easier to make a calculation on whether using that NVMe drive is worth it.
It’s unquestionably not worth it to buy an extremely powerful PCIe 3.0/4.0/5.0 NVMe drive. Just get the cheapest M.2 NVMe drive you can find because you will be using PCIe 1.0 no matter what the drive can do.
I’d still maintain that the smartest choice is probably to get a super cheap NVMe drive and use a USB WiFi adapter if you needed WiFi capabilities (and put it in the bottom USB port where we now know the I/O speeds are terrible but are still more than fast enough for USB WiFi). This will give you the excellent 17-20k I/O performance scores for very cheap. Hopefully those help you decide what makes the most sense for you!
UPDATE: I had to know if the white USB port would perform well. I set out to perform a test #3 and to my surprise it won’t even boot off the white USB port.
These findings actually have some implications. You really only have one fast USB 3.1 port. The other port below it (despite being blue) either is or is performing at the level of USB 2.1. The white port is presumably actually USB 2.0 (at best, if it was 1.0 I’d assume it would be black but all bets are off at this point since we know the bottom blue one is not USB 3.0).
That is not a nice surprise at all. This means that you probably want to use a NVMe drive so you can keep your one fast USB-A 3.1 port open. If you definitely still want to USB boot or if you have a lot of devices you need to hook up at USB 3.0+ speeds I think you are going to need a USB hub with this device!
I also have a bunch of HP USB-C hubs that would turn the one USB-C port that is open (the one not being used for power) into a USB hub. HP gives these out for free with a lot of their laptops so I ended up with a pile of them while working as a tech from users who already had / didn’t want the one that came with their refreshed laptop. That might be a good solution for some people as well (look for cheaper ones than the HP one I linked, that’s just one I can personally vouch for / have tested for reference and surely there’s cheaper options).
I suppose it could be a kernel/driver issue (meaning maybe it could be fixed/improved) but for now plan accordingly as if this device had a single USB-A 3.1 port (and 2 USB 2.0 otherwise) as well as the open USB-C port.
Hello again.
Thanks for the tests.
Can you test with the usb-c port in the middle? I believe it supports data transfer and it is usb 3.1. See if you get a difference with the white usb port.
By the way I just bought the SSD for $8.99. As I live in Spain, transport and taxes are added and I ended up paying €22.
Thank you.
Hey Jesús Vega,
Of course! So I tried to test this and just like the white USB port it cannot boot from the USB-C port (even using the SD card as a bootloader). It never detects the drive or starts up.
The only ports that appear to support USB booting are the blue ones. The top one is fast and the bottom one is slow. I could not get my same drive to boot up though using either the USB-C port or the white port as the port the SSD was connected to! These ports of course work when the OS is started up still. It just doesn’t seem to want to check them during the boot process.
It’s kind of puzzling to me that I’m not able to boot off the white port or USB-C port. The reason I say that is that I’m already “cheating” and using a SD card as my boot loader anyway. It’s booting off my SD card then it’s just supposed to look for the right root partition to mount. What is interesting about these results is that the Orange Pi 5’s boot process appears to not even *look* at the white port or USB-C port during boot up. That would probably require modifying/rebuilding uboot or whatever bootloader they are using for the Orange Pi but it does not appear to check those places (even when bootstrapping with the SD card).
In other words the bootloader Orange Pi is using does not appear to be programmed to check the USB-C port or the white USB port during the boot process. It completely ignores them which is making my usual tricks such as using a SD card as the bootloader ineffective (as the bootloader isn’t looking on those ports for our root partition’s UUID, but it does check the blue ports).
I think this will work out well for you. The NVMe setup seems to leave you the most I/O options and I think this will end up being €22 well spent. The drive should serve you for years to come as I only expect more single board computers (and eventually the Pi itself) will have the same slot. It’s getting to the point where it’s hard to find a quality SD card cheaper than some of these NVMe drives are going for!
What about the GPU? Is t recognised on Ubuntu or Debian?
Hey Antoine,
Yes, absolutely, the GPU is recognized out of the box with the Ubuntu/Debian distros!
My 8 GB board is on its way and will hopefully arrive before Christmas. I’m trying to gather together everything that I need. Do you (or anyone else) have a recommendation for a WiFi/ Bluetooth dongle? I’d like to get one with both so I’m only using one port. I have several separate dongles but apparently this board is a bit picky. Thanks for your review. It has been helpful and I’m passing it on in other places.
Hey Kattz,
Welcome, that’s such a great question. I desperately tried to find any reference to Orange Pi’s official wireless module for the Orange Pi 5 before publishing this but there’s not much out there yet.
I’ve only been able to see one place you can get it. It’s with this bundle on Amazon. They are offering the custom WiFi PCB with this bundle for some reason but I haven’t been able to find a standalone listing or even a reference to it. Look carefully at the Amazon options as you click through the different listings (there isn’t really a pic of the WiFi module) but you’ll see the description updating saying they’re including it in that one.
Okay, so what could you use alternatively? I gave this some thought before publishing and one idea I was thinking of recommending was using the ODROID USB WiFi adapter. Why? Because even though there are hundreds (maybe even thousands) of different USB WiFi adapters on Amazon including ones promising Linux compatibility I know the ODROID one basically will work plug and play with all SBCs and flavors of Linux I’ve tested it on. I know this one would work and I only didn’t include it in the article because it just seemed weird to recommend an ODROID-branded USB WiFi adapter on an Orange Pi article. This would be one safe bet though for sure (has Bluetooth but not BTLE). I also personally used this one to test to make sure it worked.
I have a few other ones like EDIMAX adapters but they’re all older models that are harder to find on Amazon. A pretty good test on whether they would work is to just plug them into a Raspberry Pi or another Orange Pi / ODROID. If it works with Debian / Ubuntu on those boards then it’s extremely likely that it will work fine with the Orange Pi 5 as well on their Ubuntu / Debian distro. The best ones to use will be using chipsets that are mainlined into the Linux kernel and don’t require any type of extra drivers to work (that’s how you get the plug and play at least, as well as it working on ARM without having to build a driver).
When people say it’s picky with the USB WiFi adapters I’d say that’s pretty true for Linux SBCs in general. A lot of the old ones that people expect to work plug and play with Linux on PCs haven’t traditionally always played nice with SBCs (or maybe when taken to ARM is a better way to put it). I’ve found though that if you find one that works well with one ARM-based single board computer using Debian/Ubuntu (as in you plug it in, Linux detects it and it just works) then this will generally remain true across the different competitor boards. It’s finding that initial compatible one that is tricky (because once you have one it usually will work with all of them).
You can generally google your adapter (or often the more important detail is the chipset inside your adapter like Realtek XXX, Atheros XXX, etc.) with “Linux mainline kernel support” and get an idea of whether it has mainline support. The reason this is so desirable is that if the driver code is in the Linux kernel then *all* versions of Linux newer than the version support was added in will support it (unless the person/organization compiling your kernel specifically disables support for them). Even more importantly though is that this also means it will support ARM and other architectures out of the box. If your Linux kernel works/builds for ARM and the code for your WiFi device is in the mainline Linux kernel then it will “just work”.
Hopefully we will see a standalone listing from Orange Pi for this as I don’t see one on their official store yet. I still can’t even find a picture of the additional module. Hopefully that helps give some ideas at least!
Thanks a lot.
It has become completely clear to me that there are two usb ports (white USB-A and the central USB-C) that are not checked at boot.
As you comment, it would be possible to boot with an SD and after boot if you have a copy of the system on a usb disk inserted in these ports, in which it is impossible to start the boot. Prepare the boot script to mount the partitions of those disks on the partitions of the SD.
Thank you.
It’s an idea of what it would be like. I’m not saying try it. My english is not very good lol
Hey Jesús Vega,
Great question, absolutely! So this is actually exactly what I did. I did this for all 4 tests. I never did a straight SSD boot and always used a SD card even with the NVMe drive. I’m not sure if everyone is doing this but I just assumed that it wouldn’t naturally boot from SSD and used the SD card anyway.
If it does boot from SSD natively I haven’t tried that yet. I almost never expect it to work as very few devices have boot loaders that support doing this (ODROID and Raspberry Pi come to mind). I did use the SD card to try all of these for sure. Hopefully that helps!
Hello. Your specs are wrong. Wrong CPU indicated.
Otherwise thanks for your website.
Hey bob,
Oh who knows what it’s supposed to be Bob. Check out the Orange Pi 5 Wiki page. At the top of the Wiki we’ve got:
Nice. Okay let’s scroll down now to the specifications:
Rockchip RK3399 (28nm HKMG process)Oh boy. That’s the one I posted from their official spec sheet. Now what does Linux say?
orangepi@orangepi5:~$ uname -aLinux orangepi5 5.10.110-rockchip-rk3588 #1.0.2 SMP Fri Dec 9 14:54:26 CST 2022 aarch64 aarch64 aarch64 GNU/Linux
Wow, amazing, all 3 of them disagree! I really wouldn’t be so sure especially if you’re going off the official documentation (which I’ve shown does not match and is a mess). At the very least we know for sure it’s not a RK3399 despite the Orange Pi 5 Wiki page still stating that today (but only on the spec sheet and not within the Wiki article).
I mean I can see what probably happened here. There’s 2 CPU sections and the one at the top is wrong. It looks like they copy/pasted and didn’t delete all the previous rows or something but it’s a pretty big mistake to make on your official Wiki’s spec sheet and it’s not the first time I’ve seen it. Whoever publishes and maintains these has a tendency to do this over there.
I’ve updated it to say RK3588S based on what Linux says (even though there’s no indication of an S within Linux but this isn’t necessarily unusual). Whatever the marketing monikers on this processor were meant to be Orange Pi blew it when they gave the wrong CPU entirely in their official Wiki’s specifications sheet (still listed today wrong). Is it the S or is it a RK3399, or is it a plain RK3588 as Linux is suggesting? Again, who cares, you cannot trust these spec sheets and we need to test it.
If you wanted to find this out definitively you would probably need to put the CPU under a scope and find something to definitively identify it (or use some sort of RockChip proprietary tool to positively identify it including the smaller details about whether it’s really a S vs. non S and things like that).
This is why I just bench it and let the numbers stand for themselves (I never believe them anyways and always test them no matter what because they do this all the time). The RockChip naming/identification is obviously quite confusing as even their own partners can’t keep these straight. Even when you can keep them straight the purpose of these names is marketing. We really just need to look at the numbers vs. something like the Pi 4 like I’ve done here to get meaningful comparisons and leave their confusing/contradictory marketing aside.
You obviously can’t take Orange Pi’s official documentation’s word for it (which is why we benchmark it in the first place, it doesn’t matter what they say it is nor can they make up their mind)! This is not the first time Orange Pi has gave out the wrong specifications on their spec sheet. The Orange Pi i96 and other models I’ve been personally involved with routinely have these wrong on the spec sheets (sometimes for the entire lifetime of the product).
Thanks for pointing this out as it gives me a chance to explain this issue which I didn’t really cover in the review. Yeah, the official documentation doesn’t match (even with itself against other parts of the documentation) and it’s a common problem with Orange Pi unfortunately! They can’t hide from the benchmarks though as putting the wrong CPU on a spec sheet will not make it score higher when we get the board in hand and test it! In this case the wrong CPU listed in the spec sheet is actually slower so they aren’t trying to make themselves look better here (and instead are making it look weaker so I’d say it’s definitely unintentional).
uname -ais not reliable.cat /proc/cpuinfois a better indicator of the CPU.Hey Dianne,
Those won’t help with this case:
orangepi@orangepi5:~$ lscpuArchitecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: ARM
Model name: Cortex-A55
Model: 0
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Stepping: r2p0
CPU max MHz: 1800.0000
CPU min MHz: 408.0000
BogoMIPS: 48.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
cpuid asimdrdm lrcpc dcpop asimddp
Model name: Cortex-A76
Model: 0
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 2
Stepping: r4p0
CPU max MHz: 2400.0000
CPU min MHz: 408.0000
BogoMIPS: 48.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
cpuid asimdrdm lrcpc dcpop asimddp
Caches (sum of all):
L1d: 384 KiB (8 instances)
L1i: 384 KiB (8 instances)
L2: 2.5 MiB (8 instances)
L3: 3 MiB (1 instance)
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; __user pointer sanitization
Spectre v2: Vulnerable: Unprivileged eBPF enabled
Srbds: Not affected
Tsx async abort: Not affected
For cpuinfo:
orangepi@orangepi5:~$ cat /proc/cpuinfoprocessor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 4
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 0
processor : 5
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 0
processor : 6
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 0
processor : 7
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 0
Serial : b4b3165686a858ee
There’s far more commands than this to identify hardware in Linux. How about lshw?
orangepi@orangepi5:~$ sudo lshw[sudo] password for orangepi:
orangepi5
description: Computer
product: Orange Pi 5
width: 64 bits
capabilities: smp cp15_barrier setend swp tagged_addr_disabled
*-core
description: Motherboard
physical id: 0
*-cpu:0
description: CPU
product: cpu
physical id: 1
bus info: cpu@0
size: 1608MHz
capacity: 1800MHz
capabilities: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp cpufreq
*-cache
description: L1 Cache
physical id: 0
size: 32KiB
*-cpu:1
description: CPU
product: cpu
physical id: 2
bus info: cpu@1
size: 1608MHz
capacity: 1800MHz
capabilities: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp cpufreq
*-cache
description: L1 Cache
physical id: 0
size: 32KiB
Nope. This is actually less information than uname -a as far as determining the SoC package. There is no RK3588S anywhere in /proc/cpuinfo or lscpu (or lshw). You’d need to have some sort of database or part listing for all of these part numbers and manufacturer codes. It doesn’t even know how to turn 0x41 into RockChip. It doesn’t recognize them like it would Intel or AMD etc.
The things people take for granted in x86_64 like the CPU names being fully fleshed out with Intel, AMD and all of the information in there is not a thing on ARM (or RISC-V either). Linux knows only the basics it’s showing in those commands and cannot at all identify whether it’s a RK3358S or the SoC package unfortunately!
This is why I said to positively identify this you’d probably put it under a scope or run a proprietary utility. I guess having a proprietary list of all of the manufacturer part codes and matching them up manually would be another way to confirm it manually. There’s no magic hardware database where Linux just knows all of these parts though. I don’t know why you think this stuff would be in there.
There is a hardware identification database on Linux but it only gets additions if companies submit requests for it (or the people using the software do). It’s pretty limited and will almost never know what cutting edge stuff is. For that to happen the manufacturers would have had to submit the device IDs and what they are way before the product was released and the truth is most manufacturers never submit this stuff at all.
Not only that, often manufacturers go to extreme lengths to keep that information top secret through things like nondisclosure agreements and that is not how Linux works (which is why it will just show generic stuff for many of these). It will just show up as the type of ARM CPU it is and that’s about as far as I’ve ever seen for most of these.
Have you seen the articles before new GPUs launch where someone will benchmark an unreleased GPU? It doesn’t show up in the benchmark sites as the new GPU name. NVIDIA and ATI go to great lengths to keep these secret and even use codenames when preparing device IDs for their products. This should be something a lot of people who follow tech hardware news probably have seen before. The people who did the benchmark are violating their NDAs even having that limited set of information hit the internet (and you better believe NVIDIA and ATI investigate them).
It’s literally a media-wide speculation game sometimes when these unknown hardware IDs are spotted on benchmarking sites putting up blazing scores on what these could be. It’s only when it gets closer to launch that NVIDIA and ATI will update their device ID reservations (with Microsoft and with Linux and Mac OS as well) to where in the OS it will show up as the right device. That is a Windows and Linux process thing though and it’s not baked into the hardware. It takes time and resources for that to happen and a lot of companies do not ever submit their hardware or even go through this process at all. Many more will only do it for Windows and never submit them for Linux.
It’s showing you everything it knows (and it’s not much, just some manufacturer IDs and product IDs that Linux has no idea how to turn into human readable form and would only be useful with a list from the manufacturer).
I mean even on Windows it doesn’t magically know what all the hardware is. If you don’t have the driver it shows up as “unidentified device” and gives a similar product ID, manufacturer ID etc. that means nothing if Windows has no driver/database to turn that into useful information. You’d actually see the same information in Windows if Windows could run on these. You’d see the exact same IDs and it would have no idea what they mean unless you have a compatible driver for it.
It’s purely a luxury that you’re ever able to get away with this on any platform. It means the hardware you’re using is mainstreamed (or old) enough that it’s made it’s way into the hardware identification databases built into Linux. Either that or a manufacturer is providing a driver that is providing that information. These fields are almost *never* populated on ARM or RISC-V that I’ve seen. It’s always just going to be 0x41 hex codes that are only useful if you’re already using some other list from somewhere else anyway.
The only reason uname -a is even helping is because RK3588 is built into the kernel name. That was done by Orange Pi themselves. Given that Orange Pi are the ones that have the wrong CPU posted in multiple places I would say that them typing that in as the name for the kernel is also not a confirmation of what this CPU really is. None of the tests you mentioned (or even my expanded ones I mentioned) can even resolve the name “RockChip”. They can’t even identify the manufacturer let alone the SoC package.
If you want to be sure as in 100% (like for real) it either goes under a scope or you match it against a proprietary manufacturer list (or using their identification utility). This has always been true and it’s also true on PC if you want to be 100% sure. Intel and AMD both have their own hardware identification and validation utilities as does RockChip (even for Linux although I’m not sure if there are apt packages available in the Orange Pi repositories or if you’d need to manually download/build them).
There are also third party utilities like CPU-Z you can use to identify and validate the hardware on Windows. Your choices are fewer on Linux (and I’d be surprised if they identified a lot of these RockChip ones) but there are some out there. This is an exact example of this. CPU-Z only works because the developers maintain a list of what the hardware is. All of them do. It’s why they have to constantly be updated to stay useful as they do not just know what this stuff is.
There is a very limited set of information that is actually coded into the hardware itself (the hexadecimal device IDs, manufacturer IDs, device type, etc.). You can figure out what it is from this *if* you have a good list (which is how CPU-Z and similar applications work). They are only as good as the list though. If you try running a 5 year old copy of CPU-Z on a modern system built within the last year for example you can see this in action!
I received my today as well and loaded it with Android 12, then loaded 3DMark. I received ‘4454’ which is very good. I did add small heatsink on the RK3588 and the smaller chip next to it. I ran the test several times with the same results. This is exactly what I was hoping for, but agree that not adding WIFI/BT was a misstep. I do have a couple of WIFI dongles that have worked with Wintel PCs as well as couple of Raspberry Pis, but sadly they are not being recognized by Android 12. I will have to investigate why, but at least my 10′ 1080P touchscreen works like a charm. Final goal is to create $200 Android/Cloud gamepad that I am currently using with the very, very limited NVIDIA Shield TV 2019 taking out of its shell. 8GB, 128GB NVME SSD and the Mali-G610 runs circles around the Shield. Can’t wait to see what the Orange Pi OS brings to the table and as James mentioned the NVMEs are super cheap (I bought 2) so I will just flash different OS builds and swap them out. Can’t wait to try out Armbain soon as it comes out as well. Really happy with my $84 early stocking stuffer 🙂
Hey Owl Creek Tech,
Great results and findings! Those are very interesting results with the USB WiFi adapters. I would have assumed the exact same thing as you (that most of these would have worked plug and play). In fact I believe if you tried in Linux this would almost certainly be the case (and it sounds like you’ve used some of them with the Pi before which would further confirm that). Definitely let us know if you find a good way to address this in Android. I’m definitely not as strong with Android as I am with Linux but I’m always trying to learn / discover more.
I’m very excited for this build. I think the Orange Pi 5 sounds perfect for it honestly and you’re getting quite a bit more firepower. I’m also looking forward to an Armbian release. Armbian always does such a great job and it will be very nice to have the nand_sata_install script that is included with Armbian. That should let people directly image the SSD from Armbian booted up on a SD card for example as setting up NVMe booting can be a bit tricky manually. It’s definitely a lot easier / faster to get a NVMe drive imaged with the convenience scripts.
Thanks for sharing, what a great $84 early stocking stuffer! It’s amazing this board is < $100 for what we're getting. Enjoy and take care!
Sadly the weather has delayed the two USB WIFI dongle variants. One looks like it might be lost :(. I am being lazy though instead of downloading there Android source code and seeing what it compatible.
I just received WaveShare’s new 8″ IPS 1280P screen with speaker drivers which highlighted another misstep by OrangePi and that is the mounting holes. Not sure why, even if the board is a little bigger, why they couldn’t make the mounting holes the same. So many screens and cases would still accommodate this board otherwise. I guess I can create and 3D print a plastic shim with threaded mounts to attach the OrangePi and after bolting it the standard RaspberryPi mounts keeping it as think as possible to ensure clearance.
FYI There is also company who is making 8″ tablet with 8 or 16GB and 128 or 256GB storage (plus SD card) for about $250. Still in the production phase, but moving forward with a sample. This could make for interesting competition to the Razer Android gamepad coming out 2023.
Hey Owl Creek Tech,
Welcome back! That is not good news that the weather has delayed the USB WiFi dongles! We’re definitely having the “bomb cyclone” in the US which has frozen out nearly half the country so a lot of people are likely in the same boat. We got skipped for Utah for this storm fortunately but we have ones moving in for later this week.
That’s an interesting idea to make a 3D printed plastic shim with threaded mounts to attach this. If you do this share the design/file here if you wouldn’t mind (we did have one 3D printed case design shared here). That sounds incredibly cool and useful.
Definitely let me know if you learn more details about the 8″ tablet Android gamepad competitor as I’d be curious to investigate this as well!
cpu benchmarks please. I what to see how it’s compared to raspberry pi 4 and now it behaves on full load (temperature and throttling)
Hey Cpu is more interesting,
Yes, there is a very good reason I didn’t do this yet. I’m still waiting for a heat sink for it. It would not be fair to do CPU testing with the bare chip as it will throttle you back way, way more (and faster) than it will with a good heat sink on it. The temps get very “spiky” running bare as there’s nowhere for the heat to go but to the air directly from the chip (instead of the heat sink serving as an intermediary and also increasing the surface area).
I have a kit of 100pcs of various copper heat sink sizes coming (meant to fit just about any SBC chip) to avoid this problem in the future. It was supposed to beat the Orange Pi 5 here but it didn’t. I’m looking at the tracking # and it says it cleared customs on November 20th and USPS has been waiting for it since November 22nd. Ugh. That package is probably lost or something. I just ordered a couple of small kits from Amazon that says they’ll come on the 16th and I’ll contact Geekworm about my larger kit that is stuck.
It’s supposed to technically run okay without the heat sink according to Orange Pi (and it did for my initial testing and I/O benchmarking). Running fine though and achieving maximum performance / benchmarking are not the same thing and doing this type of testing directly on the CPU without the heat sink would be misleading. Anyone interested in the CPU benchmarks is not going to run it bare (myself included) since we can be 100% certain that it will not perform as well bare as it will with a $2 part on it to dissipate heat.
They definitely aren’t claiming that it won’t throttle less with a good heat sink on it (it will). Raspberry Pi says the same thing about the Pi technically not requiring the heat sink and everyone knows it’s not a good idea to run those without a heat sink and that throttling comes into play more without one (just like any silicon-based electronics basically, which is an advancement from when they used to literally fry themselves before throttling was widely implemented as a safety feature to prevent the temperature from ever getting to a critical point).
I will update and add these to the review as soon as I get my heat sink for it!
3200. The score for the 3588 on cpu benchmark website is 6000…
It’s not a RK3588. It’s a RK3588S. This is important because the RK3588 has PCIe 3.0 and the RK3588S has PCIe 3.0 removed (very unfortunate). It’s the cut down “light” version.
You may want to refer to these scores here. GadgetVersus has a better breakdown than the cpubenchmarks web site. The scores are pretty identical for CPU performance since it was features that were cut and not the number of cores or frequency. That’s a pretty great resource since it has not only the RK3588S (the real one) but a lot of comparable models making it easier to see the differences between these.
CNX Software has a pretty good breakdown of the differences:
The most notable changes are the removal of the PCIe 3.0 interface, the addition of three CAN bus, and a smaller number of video output/input, Ethernet, USB, and PIPE PHY interfaces.Man, I really wish we had got the PCIe 3.0 interface. Someone actually mentioned to me on Twitter that they were a little disappointed by the top-end NVMe scores. It’s because the PCIe 3.0 interface got cut so it has to fall back to lower versions (PCIe 1 according to GadgetVersus above). I definitely second their disappointment because so many single board computers that have PCIe capabilities don’t have PCIe 3.0 (it’s more expensive to include). The Orange Pi 5 would have stood out even more if this had made it in and we didn’t get the cut down version.
This is why I disagree with the whole “CPU benchmarks are more interesting” thing here. Not really. You’re being misled by CPU benchmarks as those will not tell you that the PCIe 3.0 interface was cut on this device. The CPU benchmarks are identical between these. Are they the same though? No. You’d miss it without I/O benchmarking which is exactly why I do it.
I/O benchmarking is generally testing how fast we can write to your storage device. It’s my primary method because you cannot hide bottlenecks from I/O testing. For you to get maximum I/O testing scores you cannot have a cheap/bad CPU, cannot have cheap memory, can’t cut down the core/bus speeds and you can’t cheap out on PCIe lanes. All of the tricks they do to fool people with things like pure CPU performance testing won’t work. Everything needs to be working well *together* in the right proportions for I/O benchmarking to come out correct.
This is *especially* something to watch out for on single board computers. They have to cut corners to try to get anywhere near the Pi on pricing. The manufacturers know how to do it without it showing up in the benchmarking scores that the majority of people are looking at. This is the Orange Pi *5*. They’ve been doing this for a long time and they’ve survived in a market where many competitors haven’t.
It’s hardly unique to single board computers though. The manufacturers have been doing this with CPU/GPU testing *forever*. They plan their launches around some of these benchmark numbers. They’re very aware of all the price/performance ratio lingo and they calculate/plan it each generation. They’re also notorious for cutting down on things like memory bus bandwidth and other metrics that most consumers don’t look at. But these of course do matter. They know most people won’t notice those cuts though whereas if they dropped the clock speed of the device by even 50MHz this would have a devastating backlash vs. cutting the memory bus width.
There are a lot of ways to play games with these numbers when you know that a certain # of consumers will *only* look at the top CPU performance benchmark score and literally nothing else. Don’t be that consumer (for your own sake and everyone else’s sake don’t reward this behavior). It does matter if your devices will only work over PCIe 1.0 even though this won’t change the CPU overall performance score on cpubenchmarks a single point.
I’d really encourage people to understand that the manufacturers know all of your lingo. They know the benchmarks you favor. They know your weaknesses and they’re exploiting them. Their marketing department is counting on it and you have to evolve and start using more comprehensive benchmarks if you don’t want to fall victim to this. Make them plan a product that delivers good performance all around and not on very specific metrics. They are very comfortable with cpubenchmarks and all of these narrow ones that have been around forever (which is exactly why you shouldn’t be).
The people absolutely obsessing over this cpubenchmarks score are literally playing right into their hands. The product design decisions such as cutting to the RK3588S is designed to trick people *exactly like you* and they’ve been doing it for multiple board generations. The manufacturers know the very narrow range of benchmarks they can’t touch because it’s all you’re looking at and then everything else gets cut and you think you’re buying some god-tier board. These consumers won’t change in an industry defined by change and it’s sad because people like this think they’re doing their research.
Your research needs to evolve just like the manufacturer’s techniques to trick you evolved. It’s not smart to look at benchmarks the way we did 15-20 years ago (which is how I view what you’re doing here). We literally know better now but some people didn’t keep up. If you are doing something the same way in IT that you did 10-20 years ago then it’s because you’re comfortable and have fallen behind.
The game has changed. Sure, the people who don’t look at benchmarks at all are still completely uninformed consumers. Unfortunately that doesn’t make the people looking at pure GPU and CPU benchmarks the informed consumers. No, those are the misinformed/misled consumers that have fallen for the very targeted design decisions made so that those people do not spot any of the product’s real flaws. The informed consumers are using more comprehensive benchmarking than this in the 2020s.
At any rate there are some other benchmarks as well to check out and the scores are pretty similar (about 6133). It also remains an amazing value and top recommended board at least from me. The benchmarks have done nothing but solidify that in my mind!
I’m not saying it’s perfect though and in fact I’m saying you should probably be aware that the PCIe 3.0 interface was cut limiting your NVMe performance score potential as for certain people that may really have an impact on what they wanted to do with the board such is if someone wanted to invest in a 4TB NVMe high performance drive to make some kind of storage server. You’d want to buy a more expensive board for that use case but if you’re comparing it against the Pi then obviously the Pi doesn’t have any of that stuff either (and performs slower on every benchmark save FPU raytracing).
May I ask if the Linux supports the GPU A610?
Hey Tony,
Yes I didn’t encounter any issues with the GPU support. The GPU is recognized and benchmarked very well!