My Odroid-C2 runs a mainline kernel. I use it headless, so I'm not sure about graphics support, but its been otherwise extremely stable. It did take a year or two after release to get full upstream support. I'd imagine this new board will follow a similar trajectory.
But, I dont have one to test - it certainly might ship with a weird hacked up bootloader or something. I do have a board based on an earlier generation Amlogic SoC that I'm quite happy with. Worked well out of the box and has continued to do so.
If you want to stream high-quality content neither this one, nor it's older brother N2 are not suitable due to DRM and other issues. You'd end-up spending to much time to troubleshoot all problems.
Edit: I own Odroid N2, spent several weeks trying to make it working well. At the end I've given up and got an Intel NUC device.
I don't know what that person is doing with a pi 3, but my experience is that retro pi works well but modern video or web browsing is not going to hold up.
It's still a pain in the ass watching a 720p youtube video on Raspbian+RPi 4 from Firefox. It's barely fluid when windowed while stutters as hell in fullscren with the CPU constantly overheating, and 1080p is much worse.
Under Kodi it's way different, of course, still I wonder why one can't have video acceleration on the desktop.
It's complicated. Basically, when you are playing Firefox, there is a lot of memory copying going on.
If you download your youtube videos beforehand using youtube-dl and play using omxplayer, the result is virtually glitch free.
A better option is to install the YouTube extension on top of Kodi on Raspbian. You might also need to disable the new OpenGL driver as well. Once that is done, Kodi (which has Pi GPU patches in place) can play YouTube at 1080p30 beautifully.
"A better option is to install the YouTube extension on top of Kodi on Raspbian."
Yup, that was how I watched Youtube videos for years (although Kodi was on LibreElec).
Now unfortunately all Kodi extensions using Google APIs require registration, which of course is a huge privacy violation since I'm (still) not forced to do that on browsers.
Yep, Pi2 was totally OK as a video playback machine unless you were trying to play H.265/HEVC files, in which case it'd struggle with them over SD resolutions. Pi4 adds hardware decoding for that so now it's fine.
It's perhaps a bit dishonest to show a "UHD 4K video" being displayed in Firefox and YouTube when there's no confirmation at all what kind of video mode the player is running. It's probably 1080p or maybe 720p.
So according to 7zip and unixbench benchmarks RPI 4 with out of order CPU on 1,5GHz is on par with Odroid C4 with in order CPU on 2GHz. And the price you'll pay to get one will be closer to 70$ in EU including shipment costs or reseller fees.
Or if you need known-new boards, especially in quantity, though RPi has its own availability limitations for commercial use IIRC.
Power and Size restriction can be a bigger deal than you've made it sound, though. I can fit ten Pis in a carry-on without concern if needed, and I have needed to do so in the past. For noise reduction, fanless is better than muffling a fan, though one does need to make sure the heat sink is big enough.
>For $30 I can get an used H61 board, i3-2100 and 4GB DDR3 RAM. That is going to be much faster than both Raspberry and Odroid.
This is great. If you absolutely do not care about power efficiency, physical size, noise or reliability.
They aren't even comparable. And even if you claim to care about raw performance, I'd like to see how well that i3 does in a direct benchmark. It might not turn out the way you think it is.
There's a difference in power consumption. The C4 is 720mA loaded. The RPI4 is an oven.
C4 comes with a large heatsink. Rpi4 doesn't despite the much higher power consumption, forcing you to add one.
My conclusion: The RPI4 is an unreliable, poorly engineered toy (like every other RPI in the past). The C4 is rugged and a good choice to base projects on, like every Odroid has been to date.
Odroid units are not really plug & play. Software matters and the raspberry pi ecosystem is just better. I want to say the N2 is hands-down better than the pi, but if you deviate even a little (eg, try to add a third-party touchscreen that works perfectly fine on the pi), you'll quickly find things not working and no support from anyone.
In Europe RPI 4 with 4 GB is EUR 60, so even with lower shipping fees the price would be about the same. In some benchmarks RPI 4 is slightly faster, in others it is slower.
So neither price nor performance favor strongly one over the other. Depending on the application, the included WiFi of RPI 4 may be more useful, or the included 4-port USB 3 hub of ODROID-C4 may be more useful. For myself, the 4-port hub is more useful.
For some people, including myself, much more important is the fact that the RPI 4 CPU implements an obsolete instruction set, unlike the ODROID-C4 CPU, which implements the better ARMv8.2-A instruction set.
There is only one other cheap computer with ARMv8.2-A: Khadas VIM3L (a little more expensive, less DRAM, WiFi included, another variant of the same processor, no USB hub but PCI-E on an expansion connector).
Anybody familiar with emulation on the Amlogic? I'm looking for a good SBC for months now for HTPC & Emulation and was shortly before ordering a VIM3. However, I read somewhere that Amlogic processors are not good for GPU tasks like emulation due to unsupported drivers. Therefor, I looked at other Board like the Rockpi N10. What you guys think?
1) x86 is pretty much always easier and better for (I assume, as you mentioned HTPC, that you mean) game console emulation than other architectures, so if you don't have to have an SBC get a cheap, small x86 machine. Consider used small-footprint business workstations.
2) Raspberry Pi has much better official and (especially) community software support than other SBCs. Things like bluetooth or wifi are usually supported better there, with fewer quirks and breakage, and software's usually more up to date generally. You're rolling the dice with anything else if you're looking for something you won't have to spend a bunch of time fiddling with or fixing all the time.
2) Raspberry Pi has much better official and (especially) community software support than other SBCs.
I disagree, as my experience has been the opposite of this. RPis are always a quirky mess, where doing anything but using turnkey appliance-like solutions is painful, and even these turnkey solutions suffer from poor quality.
It's a low-effort, low-quality ecosystem, and my experience has been better with each and every one of the alternatives I've used.
I'd pick among the boards that use the A20 (ARMv7) or the A64 (ARMv8 aarch64), as these are the better supported chips.
Amlogic, iMX6, iMX8 and rockchip also have good reputation, from what I hear from my acquaintances. But I haven't tried these myself.
Broadcom (used in RPI) is infamous, and it's a much deserved infamy. I've had nothing but trouble with them, be it SoCs used on RPIs or other chips made by them.
iMX6 is fine if you can live with the underpowered GPUs, although I couldn't name a cheap universal SBC based on them, I've mostly encountered them in SOMs in professional products. iMX8 is mixed from what I've heard, pretty bad hardware issues initially, and iMX8M specifically is good. Similarly don't know a good SBC yet.
Being cheap and widely available still does a lot for the Raspberry Pi for DIY purposes IMHO, but I would be wary to base a product on it.
This has an A55, which I don't think is competitive with the raspberry pi 4 A72. The pi 4 was a huge breakthrough because it has a multi core out of order cpu and starts at $35.
Something that people would buy over the pi 4 will have to be a later generation A7X cpu without being more than double the price.
The better the CPU, the closer it comes to a lightweight desktop replacement, child computer, TV computer, router replacement etc. The pi 4 is already getting into that territory.
Apart from that, I really think there's a gap on the market in terms of RAM. Only since recently are there a select few SBCs with 4GB RAM, anything higher than that and you're in the 200~250$+price-range with significantly higher footprint in terms of size and power consumption.
It might be my personal ignorance, but I just don't see why you couldn't take any of the more recent SoCs and throw at least 8GB on there? Do some of these SoC vendors limit the address space or something..?
Right now this model is a nuanced alternative to the Rpi4B; a model with more RAM would be a new segment in the market unlocking new possibilities.
Some vendors do seem to limit their address space, there have been suggestions that they just pasted an AArch64 CPU into one of their existing ARM SoC designs.
>which I don't think is competitive with the raspberry pi 4 A72.
The power efficiency is certainly competitive. Very competitive.
Raspberry Pi has a lot of justifying to do, regarding its much elevated power consumption, as the benchmarks do elucidate it actually doesn't have the performance to show fort it.
Is it possible that they might be relying on mounting frames for metal enclosures or wired grounding near the power supply connector, just to avoid ground loops?
Maybe, I don't have another eMMC board to test with, but compared to my RPi 3 with an SD card, the eMMC feels way faster. Very noticeable doing an apt upgrade. Note I use all of my boards headless.
A microSD card is just MMC that's socketed instead of being soldered to the package/board. It's good for flexibility. With 4GB RAM, performance should be a non-issue either way.
....over a narrow bus, and with controllers that have to make assumptions about power being yanked at any moment so they can't do proper SSD-like things that eMMC chips can do.
Narrow bus? I think current SD card standards can go way past 1GB per second (note: see edit below). It's an implementation detail.
In practice, these cheap boards will have a cheap eMMC soldered in that can't do these fancy things anyways. It's not going to be same quality chip like in flagship phones.
Once that cheap eMMC fails, the device is bricked.
Edit: SD card standards still can't go past 1 GB/s, max 985 MB/s. Either way, plenty for cheap SBCs.
I don't think even flagship phones have "quality chip" inside. Phone OS's are still running without swap memory support to cope with poor quality of their onboard eMMC (which leads to OOM-killing "background" apps instead of just swapping memory out.)
SD cards as present on Raspberry Pi, even the Pi 4, don't go beyond ~60MB/s. Older Pis get around ~20MB/s. It's the worst bottleneck of the system. Where do you get that 1 GB/s figure from?
Bear in mind that SD Express is SD only in name and otherwise it is just an NVMe in SD form-factor. And how much UHS-II is still an SD is somewhat questionable.
odroid boards use a modular eMMC design. You can buy the size you want and swap them out if one fails. You can even see that in their picture (label M).
I wish more people understood this. People should demand higher quality SD cards (and slot controllers) instead of insisting on soldering equivalent chip on the board!
Of course wouldn't say no to M.2 slot (or similar) either. :-)
Yeah, the read performance is like 10 times faster than a microsd on an rpi4. Also having your boot drive in eMMC is less of a risky because they are usually more reliable than microSD.
eMMC does have a wider bus and dual edge clocking so it's not a straight comparison. I think read might be fundamentally faster on eMMC but writing mostly depends on the NAND chips used inside.
UHS-I did add a dual-edge mode at 50MHz, but SD never got up to the 8 bits MMC supports (also at about 50 MHz, so UHS-I should be roughly half the speed of high-end MMC). UHS-II went to LVDS instead, which despite using fewer lanes can support much higher clock rates, so it’s not immediately obvious which is theoretically faster with newer versions. I need to get to work or I’d do the math.
UHS-3 doubles the LVDS speed, and SD Express turned them into a PCIe lane. I haven’t kept up to see what MMC standards have been added lately, if any, but my impression is that it has been stagnant for a while.
Q: The SD-card speed increase is very welcome! Was an eMMC or M.2 slot considered?
A: We don't think there's a compelling advantage to socketed eMMC over SD. M.2 would have been fun, but we didn't like the form factor considerations, and had no spare PCIe lanes. I think USB 3.0 SSDs are the way to go for high-performance storage.
This looks like a compelling alternative to Rpi4B, and I'm happy they went without WiFi/BT. I really wish we saw more boards like this with PoE support, though - if nothing else as an optional hat to the board.
Yup, and so does Rock Pi (I think they're even cross-compatible). Unfortunately the official Raspberry hat maxes out at 2.5A, which starts being problematic if you add a single power-hungry peripheral, like an external USB disk. I've even gotten warnings on insufficient power in dmesg with zero peripherals attached on a 4B+.
So far I had no issues with DSLRKIT's third-party hats, though!
Because I have zero use for it. Components add cost and footprint. I am uncertain on if the power consumption goes up from these modules being there idling when modules/drivers are not loaded, but that could be a factor. And the less black-box non-open components on my board, the better.
I'd wager that the addition of an additional wifi-free spec would actually increase costs. With the need for active cooling to prevent throttling, the pi4 veers much closer to an ultra-small desktop replacement and for that, the integrated wifi is better.
Oh sure, I'm not saying it was a bad choice to put BT and WiFi on the RPi, just that I'm happy that there are hobbyist/prosumer devices in the same range without :)
I love the non-radio C4, my beef is that the fan kicks in a lot and is annoying. I’ve throttled back the parameters for the fan, but actually I’d lean toward passive cooling or a big constantly active case fan with a heat sync. I forget if if has video playback hardware for headed use, as I used it mostly for compute demos. IIRC it has multple processor cores with different strengths as opposed to the other tiny computers with uniform cores. Sadly unlike many of the boards out there, it doesn’t have the uniform RPi size/hat shape, unsure if C2 stuff works with C4.
Someone need to build a marketplace where you can rent these new little boards that come out. I'm probably buying one every quarter, play with it for a day or two and throw it on the pile.
Not specifically eBay, I meant all sorts of second-hand selling methods, from Craigslist through eBay and similar sites. Nothing special, really, just the normal way of getting rid of stuff which just ends up taking up space otherwise.
I hope next Raspberry Pi will finally upgrade to 64-bit memory bus. 32-bits is just too narrow. If the price is an issue, lowest $35 tier could still be 32-bit.
Thank goodness it's a regular HDMI connector. The mini and micro connectors used on certain Pis add $5 to the cost the moment you want to actually use a display.
More like a bimonthly 5$ for every time the connector breaks, unless you leave it in place and never touch it. micro-HDMI connectors are ridiculously brittle.
(Had those interfaces on two laptops and I sighed deeply when I saw that the RPi 4 had them as well)
NVIDIA Graphics cards, even my lowly GTX 1050, have an encoder called NVENC. I don't use it though with my DVD rips though. When I tried using NVENC, it was a bit faster than CPU, but the resulting file size was significantly larger to get a similar quality level. Basically, NVENC was faster, but significantly less efficient than CPU encoding is.
Because of that, any hardware encoder needs to be tested thoroughly before you start encoding on it. It could be awesome, or you might not care about the larger filesizes than CPU, but you need to do your research. However, at $50, what do you have to lose? I'm just saying the odds of this board's ARM CPU being better than NVIDIA's not-great encoder is slim.
The only other thing I'd point out is that Graphics Drivers for ARM are a very, very mixed bag. Just because it supports H.265/H.264 encode does not mean the software support is there. I remember a few years ago when the first Chinese Pi clones started coming to market. They bragged about how the hardware supported H.264 4K Decode - but didn't mention that the drivers to support hardware acceleration of even basic GUI functions weren't there. Again, do your research, but $50 is probably a good experiment.
I don't dispute the faster part, but I do dispute the end result. The end result, in my experience, is always a larger file size for similar quality than even a CPU set to High speed in Handbrake.
That's not likely a good idea unless your video collection is already very poorly encoded. In addition to the rant below, re-encoding from a regular video codec to another regular video codec is guaranteed to result in some loss of quality (I say "regular" because there are codecs specifically intended for this use-case like ProRes or H264's SVC).
I think there's a widely-held misconception that the codec is the defining characteristic for video compression performance, that the codec is like a step-by-step procedure that all the encoders and decoders implement, so the choice of codec is the most important choice and different codecs are better or worse than others.
This mostly isn't the case.
You can think of a codec as something more like HTML + CSS + JS: there are some standards that define what your program can write and how it should be interpreted by other programs that read it. For a particular end-goal, there are many ways you could go about it. For example given a mock from a designer for a static webpage, you could produce a working copy by writing it up with clean HTML and CSS, with dirty HTML and CSS or you could just make a HTML page with a single <img> element. All of these could produce the same result but they go about it in vastly different ways that perform very differently.
The same is true of video codecs. Different encoders, given similar parameters and the same inputs, can produce vastly different results, with vastly different performance characteristics. This is especially true of encoders with odd constraints, like hardware encoders, which are usually forced to do things very differently due to not having the same amount working memory, being power-constrained (especially on phones and SBCs) or not having enough space on the physical silicon to implement certain approaches.
You can see benchmarks for some modern HEVC and AV1 encoders from MSU [0]. To see how different things can get, have a look at the 4K chart [1] and switch the "Plot Type" to "Speed/Quality". You can see that on one end, the Bytedance V265 encoder gives a 20% bitrate saving relative to x264 while taking half the time. On the other hand, the x265 encoder only gives a 13% bitrate saving despite taking 28% longer than x264. This is despite both V265 and x265 encoding the same codec.
As for hardware encoders, reliable benchmarks are usually sparse but in general, there are two classes:
- The kind used in embedded devices (phones, cameras, SBCs etc.) - these are usually built as accelerators so that the device's low-power CPU doesn't have to perform the computationally-intensive (and therefore energy/thermal-intensive) task of encoding video. They're usually built to handle realtime video, maybe slow-motion video and in terms of compression, they're not great.
- The kind used in less power-constrained environments (e.g. as part of a dedicated PCI-e video encoder card used in a video workstation, or the kind added to a GPU or CPU) - these are also built as accelerators but they're no longer anywhere near as constrained by thermal and energy considerations. They're usually not able to reach the same kind of compression as a software encoder due to some techniques just being entirely out of the question but they're able to process video very very fast. NVIDIA's NVENC encoder is the best that I've tested here.
If you really want to re-encode your library, I'd recommend getting a modern NVIDIA graphics card (recency matters a lot more than power) and using that instead of the SBC. It should be a lot faster than the SBC and the compression will be a lot better.
EDIT: Also, I forgot to address the "and different codecs are better or worse than others" comment near the start of the post. What I was getting at here was mostly the widely-held belief that AV1 is "slower" or more computationally-expensive than HEVC. This isn't the case but I believe originates from comparisons of the...
Could you elaborate? I've tried boards from a couple of different vendors and if anything, the proprietary stuff needed for Raspberry Pi has been the most frustrating for me (apart from Android TV Boxes, but hey, we weren't "supposed" to run Linux on those in the first place).
The 3B and 4B have their own different hacks needed to get normal Linux distros running under 64bit, and it's nothing you can expect an average hobbyist user to figure out even with the resources put out by people in the community who have succeeded (unless they just flash some unsigned image containing god knows what uploaded out by some rando on a forum).
Why should it be fast to have SATA 3 support? They just have to integrate a SATA controller. NAS boxes have pretty weak CPUs and I thought these cheap ARM boards could be used in NAS if there was actual SATA 3 support.
This is despite common, cheap SoCs having PCI-e and DDR4 interfaces. This includes the SoC used in the RPI4.
It would be a matter of making a proper breakout board. It could be a hobbyist project, like so many available. Order the board yourself and solder everything yourself.
But nobody has bothered. I do wonder why.
My intuition is that everybody is waiting for a friendly RISC-V SoC to do this with. That is, that nobody actually wants to support the ARM ecosystem. E.g. I used to like ARM when it was an UK-based company. This changed as it got bought, and I do even actively dislike them ever since their "get the facts" campaign against RISC-V.
Odroid HC1 and HC2 are based off Odroid XU4 with Exynos5422 but with a SATA3 connector. They make for a little NAS in DAS form factor, about $60 to $75
NanoPi M4 ($50) has a quad SATA3 hat ($25). Not sure if that's what you meant by cheap, but its not terribly expensive. Couldn't comment on how well it works either, but the board itself is supported by Armbian on the most recent mainline LTS kernel (5.4). The Armbian system I have is rock solid, no complaints.
Yes and No. Depends on what is cheap for you? There is the Marvell Espressobin http://espressobin.net/ at around 80US$.
They also have the MachiatoBin, but that can't be considered cheap anymore, except if you need the two 10GB Ethernet ports.
Honestly i don't get the need for SATA, because since USB3 this https://en.wikipedia.org/wiki/USB_Attached_SCSI mostly compensates the lack of it. It's fast enough for the little things and has the added benefit of availability in ready to use enclosures, whith power delivery over USB @2.5 Inches. If you need more/faster, just use some recent Celeron @Mini-ITX, or so.
The highlights: 720mA on load, eMMC support and not being based on a broadcom SoC. I am tempted to get one.
The raspberry pi was that way regarding power consumption in the beginning, but it uses way too much power these days. It also has an infamously slow and unreliable sdcard interface.
Good thing is that it doesn't use 5V input directly, and you can connect it to higher voltage power supply, and don't need to worry that much about cabling and power supply quality.
Lies, Dang Lies, Statistics, and not questioning data from the company selling the board.
A55 is a 2-wide decode in-order architecture with 2 execution ports and 2.65 DMIPS.
A72 is a 3-wide decode out-of-order architecture with 8 execution ports and 4.72 DMIPS.
Obviously something is wrong here, so let's examine what it could be.
To get it out of the way, Mali G31 MP1 is theoretically slightly less performance (20.8GFLOPS vs 24GFLOPS), but my money would be on the Mali being much more efficient (the VideoCore architecture has been notoriously slower than it's theoretical numbers would indicate).
Cache is another consideration. The Pi 4 uses 1mb of L2. I can't find anything about the 905 except that it has L3 cache. The maximum L2 for A55 is 256kb. L3 can go up to 4MB. The s922x launched middle of last year and seems to have had 1mb of cache on it's A73 cores, so I would guess at less than that for a lower-end chip. In any case, I'd put cache as equal at best.
Pi 4 uses 1-4gb LPDDR4-3200 vs some DDR4-1320 on the odroid. No matter how you slice it though, something weird is going on here.
There is a default clockspeed difference (1.5GHz vs 2.0GHz), but it isn't nearly as large as the actual performance per clock difference. Since the 905 is apparently rated to run at 1.9GHz, I suspect they slightly overclocked the chips in their devices. I'd note that overclocking the Pi 4 to 2.0GHz is easily doable, but I wouldn't expect them to do that as it can lower the life expectancy of the chip (given the 8-stage A55 pipeline, I doubt that the 905 has much overclocking overhead).
On paper, the Pi 4 should be way faster at most of these things, so it must be elsewhere.
The first stop is data storage. SD cards suck. They suck so much that a spinning drive can usually get better performance. They desperately need to launch a new Pi with a SATA port or PCIe port for a faster drive. eMMC is a much better default option. The Pi loading benchmarks get 2-4x faster (sometimes more) when a USB3 SSD is used. On the flip side though, if a benchmark sits in RAM, you aren't going to notice a difference unless their benches are including load time. That may be fine for a few things, but it should be stated and it simply doesn't apply to a lot of real-world uses (for example, loading a browser may be a little slower, but opening and using web pages will not).
The next question is thermals. The 28nm Pi with larger cores definitely gets hotter and throttles more than the 12nm smaller A55 cores. If they shoved the pi into the default enclosure without a heatsink, it would definitely throttle hard which would affect benchmarks significantly. I fully expect this to be responsible for a large percentage of the performance disparity over what would be expected. Testing the raw Pi would be much more fair. A small heatsink would be more than fair and a fan would be overly-generous (seriously, pi foundation needs to recommend and sell a heatsink and redo their case design to accommodate a fan). I'd love for this to also be disclosed.
The next issue is insidious and veers much closer to evil. Using the same OS when possible should be a prerequisite for fair comparisons. Ubuntu team did some great work and fixed the major bugs that were hurting 64-bit usage (USB issues and 2-3GB RAM limit). I switched from Rasbian and there was a very noticeable increase in performance. Those fixes have been available for almost 6 months and there's no reason not to use it for their testing other than cooking the benches. We aren't talking small amounts either. 10% faster memory, 50% higher dhrystone, 15% faster audio encoding, 2x faster network performance, etc. I'm almost positive that they used Rasbian instead.
I think Odroid c4 will have a gpu advantage an area where traditionally Raspberry Pi has been weak. It takes time and tweaking to get ok graphics out of the pi. So Odroid may make for a better HTPC setup.
129 comments
[ 7.5 ms ] story [ 183 ms ] threadhttps://github.com/lategoodbye/rpi-zero/issues/43
But, I dont have one to test - it certainly might ship with a weird hacked up bootloader or something. I do have a board based on an earlier generation Amlogic SoC that I'm quite happy with. Worked well out of the box and has continued to do so.
When I tried via a web browser a while ago I couldn't get it to work well, iirc I had to install a plugin from somewhere too.
Edit: I own Odroid N2, spent several weeks trying to make it working well. At the end I've given up and got an Intel NUC device.
If you download your youtube videos beforehand using youtube-dl and play using omxplayer, the result is virtually glitch free.
A better option is to install the YouTube extension on top of Kodi on Raspbian. You might also need to disable the new OpenGL driver as well. Once that is done, Kodi (which has Pi GPU patches in place) can play YouTube at 1080p30 beautifully.
Yup, that was how I watched Youtube videos for years (although Kodi was on LibreElec). Now unfortunately all Kodi extensions using Google APIs require registration, which of course is a huge privacy violation since I'm (still) not forced to do that on browsers.
The ARM boards make sense only if you have power and size restrictions.
Power and Size restriction can be a bigger deal than you've made it sound, though. I can fit ten Pis in a carry-on without concern if needed, and I have needed to do so in the past. For noise reduction, fanless is better than muffling a fan, though one does need to make sure the heat sink is big enough.
This is great. If you absolutely do not care about power efficiency, physical size, noise or reliability.
They aren't even comparable. And even if you claim to care about raw performance, I'd like to see how well that i3 does in a direct benchmark. It might not turn out the way you think it is.
C4 comes with a large heatsink. Rpi4 doesn't despite the much higher power consumption, forcing you to add one.
My conclusion: The RPI4 is an unreliable, poorly engineered toy (like every other RPI in the past). The C4 is rugged and a good choice to base projects on, like every Odroid has been to date.
My experience is the opposite. The raspberry pi ecosystem is low quality and full of quirks and annoyances.
All the alternatives I have used (mostly sunxi-based) have been a much smoother experience.
There is only one other cheap computer with ARMv8.2-A: Khadas VIM3L (a little more expensive, less DRAM, WiFi included, another variant of the same processor, no USB hub but PCI-E on an expansion connector).
2) Raspberry Pi has much better official and (especially) community software support than other SBCs. Things like bluetooth or wifi are usually supported better there, with fewer quirks and breakage, and software's usually more up to date generally. You're rolling the dice with anything else if you're looking for something you won't have to spend a bunch of time fiddling with or fixing all the time.
I also read somewhere that RK3399 for emulation should also be a good choice, therefore I considered the Rockpi 10N as well.
I disagree, as my experience has been the opposite of this. RPis are always a quirky mess, where doing anything but using turnkey appliance-like solutions is painful, and even these turnkey solutions suffer from poor quality.
It's a low-effort, low-quality ecosystem, and my experience has been better with each and every one of the alternatives I've used.
They have excellent community and Mainline Linux support:
https://linux-sunxi.org/Linux_mainlining_effort
Support in BSDs is similarly very good.
I'd pick among the boards that use the A20 (ARMv7) or the A64 (ARMv8 aarch64), as these are the better supported chips.
Amlogic, iMX6, iMX8 and rockchip also have good reputation, from what I hear from my acquaintances. But I haven't tried these myself.
Broadcom (used in RPI) is infamous, and it's a much deserved infamy. I've had nothing but trouble with them, be it SoCs used on RPIs or other chips made by them.
Being cheap and widely available still does a lot for the Raspberry Pi for DIY purposes IMHO, but I would be wary to base a product on it.
Something that people would buy over the pi 4 will have to be a later generation A7X cpu without being more than double the price.
The better the CPU, the closer it comes to a lightweight desktop replacement, child computer, TV computer, router replacement etc. The pi 4 is already getting into that territory.
It might be my personal ignorance, but I just don't see why you couldn't take any of the more recent SoCs and throw at least 8GB on there? Do some of these SoC vendors limit the address space or something..?
Right now this model is a nuanced alternative to the Rpi4B; a model with more RAM would be a new segment in the market unlocking new possibilities.
The power efficiency is certainly competitive. Very competitive.
Raspberry Pi has a lot of justifying to do, regarding its much elevated power consumption, as the benchmarks do elucidate it actually doesn't have the performance to show fort it.
The A55 is claimed to be 15% more power efficient than the A53 while the A72 is 3-4 times as fast.
The source for Odroid power consumption is the specs mentioned in the article we're discussing.
You can check Raspberry Pi's consumption values from this table: https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications
As for performance benchmarks, the one I've seen is here: https://forum.odroid.com/viewtopic.php?f=29&t=38555
I expect more will pop up in due time.
It is not easy to pass EMC tests if you want to embed these boards into some device without proper grounding.
Might be a good accessory to sell.
In practice, these cheap boards will have a cheap eMMC soldered in that can't do these fancy things anyways. It's not going to be same quality chip like in flagship phones.
Once that cheap eMMC fails, the device is bricked.
Edit: SD card standards still can't go past 1 GB/s, max 985 MB/s. Either way, plenty for cheap SBCs.
https://en.m.wikipedia.org/wiki/SD_card
SD Express can do up to 985 MB/s.
SD UHS-II @300MB/s would be plenty for most SBCs.
While it would technically be correct, no one says new USB standard X is USB in name only.
Perhaps every data transfer interface standard eventually adopts a PCI-e lane. :-)
https://www.hardkernel.com/shop/odroid-c4/
They sell their eMMC chips here
https://www.hardkernel.com/product-category/memories/
I'm not sure you can make that "assumption" safely - plenty of SD cards have been bricked/trashed that way.
Of course wouldn't say no to M.2 slot (or similar) either. :-)
UHS-3 doubles the LVDS speed, and SD Express turned them into a PCIe lane. I haven’t kept up to see what MMC standards have been added lately, if any, but my impression is that it has been stagnant for a while.
Q: The SD-card speed increase is very welcome! Was an eMMC or M.2 slot considered?
A: We don't think there's a compelling advantage to socketed eMMC over SD. M.2 would have been fun, but we didn't like the form factor considerations, and had no spare PCIe lanes. I think USB 3.0 SSDs are the way to go for high-performance storage.
https://www.tomshardware.com/reviews/raspberry-pi-eben-upton...
So far I had no issues with DSLRKIT's third-party hats, though!
good fun though
Or is it an external binary that, for example, Kodi is using to decode?
(Had those interfaces on two laptops and I sighed deeply when I saw that the RPi 4 had them as well)
I could use this to re-encode my video collection without having to have my main pc running for days/weeks.
Because of that, any hardware encoder needs to be tested thoroughly before you start encoding on it. It could be awesome, or you might not care about the larger filesizes than CPU, but you need to do your research. However, at $50, what do you have to lose? I'm just saying the odds of this board's ARM CPU being better than NVIDIA's not-great encoder is slim.
The only other thing I'd point out is that Graphics Drivers for ARM are a very, very mixed bag. Just because it supports H.265/H.264 encode does not mean the software support is there. I remember a few years ago when the first Chinese Pi clones started coming to market. They bragged about how the hardware supported H.264 4K Decode - but didn't mention that the drivers to support hardware acceleration of even basic GUI functions weren't there. Again, do your research, but $50 is probably a good experiment.
h264 is obsolete and h265 is a poor choice anyway. I would wait for AV1 encoding acceleration.
I think there's a widely-held misconception that the codec is the defining characteristic for video compression performance, that the codec is like a step-by-step procedure that all the encoders and decoders implement, so the choice of codec is the most important choice and different codecs are better or worse than others.
This mostly isn't the case.
You can think of a codec as something more like HTML + CSS + JS: there are some standards that define what your program can write and how it should be interpreted by other programs that read it. For a particular end-goal, there are many ways you could go about it. For example given a mock from a designer for a static webpage, you could produce a working copy by writing it up with clean HTML and CSS, with dirty HTML and CSS or you could just make a HTML page with a single <img> element. All of these could produce the same result but they go about it in vastly different ways that perform very differently.
The same is true of video codecs. Different encoders, given similar parameters and the same inputs, can produce vastly different results, with vastly different performance characteristics. This is especially true of encoders with odd constraints, like hardware encoders, which are usually forced to do things very differently due to not having the same amount working memory, being power-constrained (especially on phones and SBCs) or not having enough space on the physical silicon to implement certain approaches.
You can see benchmarks for some modern HEVC and AV1 encoders from MSU [0]. To see how different things can get, have a look at the 4K chart [1] and switch the "Plot Type" to "Speed/Quality". You can see that on one end, the Bytedance V265 encoder gives a 20% bitrate saving relative to x264 while taking half the time. On the other hand, the x265 encoder only gives a 13% bitrate saving despite taking 28% longer than x264. This is despite both V265 and x265 encoding the same codec.
As for hardware encoders, reliable benchmarks are usually sparse but in general, there are two classes:
- The kind used in embedded devices (phones, cameras, SBCs etc.) - these are usually built as accelerators so that the device's low-power CPU doesn't have to perform the computationally-intensive (and therefore energy/thermal-intensive) task of encoding video. They're usually built to handle realtime video, maybe slow-motion video and in terms of compression, they're not great.
- The kind used in less power-constrained environments (e.g. as part of a dedicated PCI-e video encoder card used in a video workstation, or the kind added to a GPU or CPU) - these are also built as accelerators but they're no longer anywhere near as constrained by thermal and energy considerations. They're usually not able to reach the same kind of compression as a software encoder due to some techniques just being entirely out of the question but they're able to process video very very fast. NVIDIA's NVENC encoder is the best that I've tested here.
If you really want to re-encode your library, I'd recommend getting a modern NVIDIA graphics card (recency matters a lot more than power) and using that instead of the SBC. It should be a lot faster than the SBC and the compression will be a lot better.
EDIT: Also, I forgot to address the "and different codecs are better or worse than others" comment near the start of the post. What I was getting at here was mostly the widely-held belief that AV1 is "slower" or more computationally-expensive than HEVC. This isn't the case but I believe originates from comparisons of the...
The 3B and 4B have their own different hacks needed to get normal Linux distros running under 64bit, and it's nothing you can expect an average hobbyist user to figure out even with the resources put out by people in the community who have succeeded (unless they just flash some unsigned image containing god knows what uploaded out by some rando on a forum).
You’ll just find tons of things that don’t work when you use anything but rpi.
My experience has been the opposite of this.
RPIs have always been the hardest boards to get working.
[1]: https://www.raspberrypi.org/blog/vulkan-raspberry-pi-first-t...
[0] https://developer.arm.com/ip-products/graphics-and-multimedi... [1] https://developer.arm.com/solutions/graphics-and-gaming/apis...
Google 'armbian vulkan.' armbian is an OS that these Pi clones often run.
Still no ARM board with a decently powerful CPU, SATA3, NVME, PCI-E x16, USB3.2, and DDR4 slots.
It looks like ARM boards are pretty much the same, unless you want them for a pretty niche application.
Also, software support is not quite the best.
Or if Apple made an A13 SBC. They'd make a killing.
The CPU would be cheaper than x86 but not dirt-cheap. It should be reasonably fast to make sense for sata3 or nvme. This implies fast RAM, too.
If anything, the economy of scale won't be in favor of this board either, unless it's produced in millions.
Ampere eMag would me more suited as an ARM workstation.
It would be a matter of making a proper breakout board. It could be a hobbyist project, like so many available. Order the board yourself and solder everything yourself.
But nobody has bothered. I do wonder why.
My intuition is that everybody is waiting for a friendly RISC-V SoC to do this with. That is, that nobody actually wants to support the ARM ecosystem. E.g. I used to like ARM when it was an UK-based company. This changed as it got bought, and I do even actively dislike them ever since their "get the facts" campaign against RISC-V.
The raspberry pi was that way regarding power consumption in the beginning, but it uses way too much power these days. It also has an infamously slow and unreliable sdcard interface.
https://www.pidramble.com/wiki/benchmarks/power-consumption
A55 is a 2-wide decode in-order architecture with 2 execution ports and 2.65 DMIPS.
A72 is a 3-wide decode out-of-order architecture with 8 execution ports and 4.72 DMIPS.
Obviously something is wrong here, so let's examine what it could be.
To get it out of the way, Mali G31 MP1 is theoretically slightly less performance (20.8GFLOPS vs 24GFLOPS), but my money would be on the Mali being much more efficient (the VideoCore architecture has been notoriously slower than it's theoretical numbers would indicate).
Cache is another consideration. The Pi 4 uses 1mb of L2. I can't find anything about the 905 except that it has L3 cache. The maximum L2 for A55 is 256kb. L3 can go up to 4MB. The s922x launched middle of last year and seems to have had 1mb of cache on it's A73 cores, so I would guess at less than that for a lower-end chip. In any case, I'd put cache as equal at best.
Pi 4 uses 1-4gb LPDDR4-3200 vs some DDR4-1320 on the odroid. No matter how you slice it though, something weird is going on here.
There is a default clockspeed difference (1.5GHz vs 2.0GHz), but it isn't nearly as large as the actual performance per clock difference. Since the 905 is apparently rated to run at 1.9GHz, I suspect they slightly overclocked the chips in their devices. I'd note that overclocking the Pi 4 to 2.0GHz is easily doable, but I wouldn't expect them to do that as it can lower the life expectancy of the chip (given the 8-stage A55 pipeline, I doubt that the 905 has much overclocking overhead).
On paper, the Pi 4 should be way faster at most of these things, so it must be elsewhere.
The first stop is data storage. SD cards suck. They suck so much that a spinning drive can usually get better performance. They desperately need to launch a new Pi with a SATA port or PCIe port for a faster drive. eMMC is a much better default option. The Pi loading benchmarks get 2-4x faster (sometimes more) when a USB3 SSD is used. On the flip side though, if a benchmark sits in RAM, you aren't going to notice a difference unless their benches are including load time. That may be fine for a few things, but it should be stated and it simply doesn't apply to a lot of real-world uses (for example, loading a browser may be a little slower, but opening and using web pages will not).
The next question is thermals. The 28nm Pi with larger cores definitely gets hotter and throttles more than the 12nm smaller A55 cores. If they shoved the pi into the default enclosure without a heatsink, it would definitely throttle hard which would affect benchmarks significantly. I fully expect this to be responsible for a large percentage of the performance disparity over what would be expected. Testing the raw Pi would be much more fair. A small heatsink would be more than fair and a fan would be overly-generous (seriously, pi foundation needs to recommend and sell a heatsink and redo their case design to accommodate a fan). I'd love for this to also be disclosed.
The next issue is insidious and veers much closer to evil. Using the same OS when possible should be a prerequisite for fair comparisons. Ubuntu team did some great work and fixed the major bugs that were hurting 64-bit usage (USB issues and 2-3GB RAM limit). I switched from Rasbian and there was a very noticeable increase in performance. Those fixes have been available for almost 6 months and there's no reason not to use it for their testing other than cooking the benches. We aren't talking small amounts either. 10% faster memory, 50% higher dhrystone, 15% faster audio encoding, 2x faster network performance, etc. I'm almost positive that they used Rasbian instead.
https://medium.com/@matteocroce/why-you-should-run-a-64-bit-...
No matter how you slice it thoug...