ODROID-N2 Offer Six Cortex-A73/A53 Cores For $65~82, Good Performance In Linux Benchmarks

[L_A_G]

What I find unreasonable is taking someone to task for one extra email. Seriously, if you're that sensitive to email, then maybe email notifications aren't the right tool for you.

You do realize that this is not the first time you've done that? It's kind of obvious that I'm not the only one and it's not the first time you've spammed me like this.

How often do you run memtest? Just curious.

It's one of the first things I do when I see issues that could be caused by bad RAM. Last time I ran it was about a year ago on my workstation system and the RAM turned out to be just fine and it was just a programming error on my part. Come to think of it, I've never actually caught bad RAM with memtest and the only corrupted data I've ever had has been because mechanical disk drives failing and burned optical disks suffering from bit rot and bad burns.

It was just a bit of advice. Take it or leave it. I have literally no stake in the matter, so you don't owe me any kind of explanation or defense of your position.

Well it sure sounded like a plain rebuttal of the way I've done it rather than an attempt at giving advice.

[blackshard]

Um, how can you say it's not pushing performance per Watt? It's probably burning less peak power than your beloved RPi 3, while finishing in a fraction of the time. Yes, it has a good heat sink, but the thermal performance isn't all just down to that.

my "beloved" rpi3 (which I don't own and never owned) is just a quad-core A53, and behaves like any other quad-core A53.
This SoC is "just" a quad-core A73 + dual-core A53, and behaves like any other of its kind. There is no architectural advancement in this sense, A73 and A53 cores are quite common nowadays.

Testing the raw CPU performance of the SoC is not testing the SoC, because it has many parts: where are the GPU tests? and the VPU, how does it work? What kind of interfaces it has? Most of all, how reliable is software support?
You can have the cutting edge super-performer SoC like this, but then you can't use it to watch a film because the audio drivers are missing... quite disappointing, isn't it? (<- this is the real case for AmLogic chips in mainline kernel: to get the audio via HDMI your only choice is to use the legacy 3.14 kernel...)

[coder]

You do realize that this is not the first time you've done that? It's kind of obvious that I'm not the only one and it's not the first time you've spammed me like this.

No, probably not. I also realize that I'm probably not the first or only one to have "done that" to you. Nor will I be the last. It's kind of obvious that most people don't even care. I'm pretty sure that yours is the first complaint I've received or seen, in my last 4.5 years and 1.35k posts..

Anyway, I'm hardly replying to your posts. It's not daily or weekly, for sure. There's no way you can call this a frequent occurrence.

Honestly, you're being such a whiny *** about this, I can't say I'm moved to sympathy. I'll try to edit my replies to you into a single post, if I remember. But, just in case I forget, I suggest you also try to find a way not to be so aggrieved by the offense. Maybe setup an email rule to put these emails into a junk folder or switch them to a junk account, if not disabling them, completely. You've invested a multiple of the time it would take to do any of those things (if not all), trying to litigate your case to just one offender.

the only corrupted data I've ever had has been because mechanical disk drives failing and burned optical disks suffering from bit rot and bad burns.

Let's not get into RAIDs, then.

Most people never thought much about the quality of optical disc burns. I've always tried to buy good burners and media, and not burn at the fastest speed. Also, it used to be a good idea to keep drive firmware updated - especially when switching brands or models of blank media - as manufacturers would often tweak burning parameters based on the disc's manufacturer ID. There were some tools you could use to do quality scans, but all I'm aware of ran only on Windows and were tied to specific brands and models of burners.

I still use BD-R as a backup medium and to offload a few HD broadcasts I've recorded for later viewing.

BTW, I predict you'll be adding "stale USB flash drives" to the list, at some point.

Well it sure sounded like a plain rebuttal of the way I've done it rather than an attempt at giving advice.

Nope. Just replying to select remarks as a way to clarify and explain my original point, raising factors you & others might not have considered. There was a time that I'd have done the same as you, but I've since learned a few things.

[coder]

my "beloved" rpi3 (which I don't own and never owned) is just a quad-core A53, and behaves like any other quad-core A53.
This SoC is "just" a quad-core A73 + dual-core A53, and behaves like any other of its kind.

You seem ignorant of the power benefits derived by using a smaller manufacturing node.

The N2's SoC was built on a 12 nm node and ODROID claims max power consumption for all 6 cores is only 5.2~5.3 W (source: https://www.hardkernel.com/shop/odro...th-4gbyte-ram/).

I don't know what node was used for the Pi 3B+'s BCM2837B0, but it allegedly burns up to 5.7 W (source: https://www.raspberrypi.org/magpi/wp...Power-Draw.jpg).

There is no architectural advancement in this sense, A73 and A53 cores are quite common nowadays.

Oh, where to start? They're completely different. They're separated by several generations and by their underlying design goals. The only thing they have in common is that they're both ARMv8 64-bit cores. The A53 was designed to be a cheap, small in-order core, while the A73 is an out-of-order, throughput-optimized core.

As a result, the integer performance of the A73 is roughly 2.8x that of the A53, at the same clock speed (source: https://en.wikipedia.org/wiki/Compar..._ARMv8-A_cores). Floating-point and vector performance are likewise substantially enhanced.

Testing the raw CPU performance of the SoC is not testing the SoC, because it has many parts: where are the GPU tests? and the VPU,

I was pretty sure we were just talking about CPU performance, because the raw performance and power efficiency of the N2's GPU is multiple orders of magnitude beyond the Pi. Most SoC's out there are at least one order of magnitude beyond it. VideoCore IV is pretty stone age tech. The only point in its favor is its open specifications.

Moreover, VideoCore IV only supports OpenGL ES 2.0, while the N2's Mali-G52 supports OpenGL ES 3.2, Vulkan 1.1, and OpenCL 2.0.

Most of all, how reliable is software support?
You can have the cutting edge super-performer SoC like this, but then you can't use it to watch a film because the audio drivers are missing... quite disappointing, isn't it? (<- this is the real case for AmLogic chips in mainline kernel: to get the audio via HDMI your only choice is to use the legacy 3.14 kernel...)

All going points. Except, wrong thread. All I ever commented on was the CPU performance/power. I never claimed there's no good reason for anyone ever to use a Pi - just refuted your suggestion that the N2's thermal performance was entirely due to the size of its heatsink.

[skeetre]

WooHoo! I got my N2. It's fast. Desktop seems more responsive than my Core 2 Duo with 5 Gb ram. Updated my disk benchmarks on earlier post #60

[L_A_G]

No, probably not. I also realize that I'm probably not the first or only one to have "done that" to you.

Actually you are the only one who is disorganized enough to spam me like that. The fact that you clearly take issue with me just asking you to be a bit more organized doesn't exactly give the best impression.

Let's not get into RAIDs, then.

Yes, let's not because this really isn't one of those really high uptime systems where a day or two of downtime is completely unacceptable. Hell, with the way the thing doesn't even get daily code pushes a disk failure probably isn't going going to hurt operations in the slightest. Let's also not go into how much less failure prone today's SSDs are compared to mechanical disk drives.

Nope. Just replying to select remarks as a way to clarify and explain my original point, raising factors you & others might not have considered. There was a time that I'd have done the same as you, but I've since learned a few things.

That's really not what I'm seeing considering most of the advice you've pushed have been for much more involved and heavily used systems rather than a simple get server mostly serving two people who don't even commit new code daily. Your advice has very obviously been for a system with way more users, way more complexity in multiple branches and generally just all around production level development. What my little Git server is really doing is doing version management and code sharing for an experimental branch of a software that we sell to a fairly small number of customers and only had it's first commercial release last July.

[skeetre]

My benchmarks compared to Michael's... and a bit of comparison between kernels and overclocking.

https://openbenchmarking.org/result/1905052-SKEE-190504921

I had some strange performance issues on the 4.9.170 kernel for memory benchmarks, but seemed to do okay in later benchmarks with the same kernel. Then had some issues later with the 1.99Ghz overclock performance towards the end.

But there they are for anyone that wants to compare. Was going to try some different OSes like emuElec and Bactocera but ended up getting busy with other stuff like a corrupted hd on my Fedora 30 server, that I had just spent the weekend recompiling old muck and moo servers to get them back up and running, and now dead in the water again.

Anyone think there's a benefit or need to turn off spectre/meltdown mitigation on the N2? The a73 cores are theoretically vulnerable.

[coder]

Actually you are the only one who is disorganized enough to spam me like that.

What you characterize as disorganization, I actually see as trying to keep the discussion properly tree-structured.

It's funny how your objectives color your perceptions.

The fact that you clearly take issue with me just asking you to be a bit more organized doesn't exactly give the best impression.

Tone has a lot to do with it. If you'd phrased it as a polite request, I might've rolled my eyes but grudgingly complied without a remark. Instead, you phrased it as an aggrieved complaint, as if your getting one superfluous email was a significant hardship resulting from behavior that was clearly outside the norms of acceptable behavior.

It's primarily your tone and disproportionality that's aggravating the whole issue. In the future, I suggest you ask yourself what's more important: venting whatever frustration you might be feeling or achieving the behavior modification you seek. Failure to prioritize will likely produce a sub-optimal outcome.

Yes, let's not because this really isn't one of those really high uptime systems where a day or two of downtime is completely unacceptable.

It's funny how you keep coming back to uptime, whereas I'm really just concerned with data integrity. It's true that you can't have the former without the latter, but the latter is much more achievable and generally more important.

I've never operated a 99.999% uptime environment. I'm not really about that.

Let's also not go into how much less failure prone today's SSDs are compared to mechanical disk drives.

SSDs tend to fail suddenly and catastrophically, whereas HDDs tend to give off warning signs and are often salvageable as they degrade. SSDs also have much worse data retention, for offline storage. Just FYI. And no, not everything I'm saying is intended to apply directly to your present situation.

[coder]

Anyone think there's a benefit or need to turn off spectre/meltdown mitigation on the N2? The a73 cores are theoretically vulnerable.

Depends a lot on what you're doing with it. If you're browsing the public internet from it, then the safe money would be to keep the mitigations enabled. However, if it's just for use on your internal network, by a controlled set of users (i.e. no malicious actors) and running internal and officially-released code, then I'd say it's pretty safe to disable them.

[L_A_G]

What you characterize as disorganization, I actually see as trying to keep the discussion properly tree-structured.

Well I'd hardly call consecutive messages addressing the same person particularly well structured...

Tone has a lot to do with it. If you'd phrased it as a polite request, I might've rolled my eyes but grudgingly complied without a remark. Instead, you phrased it as an aggrieved complaint, as if your getting one superfluous email was a significant hardship resulting from behavior that was clearly outside the norms of acceptable behavior.

Seeing how you consider even a polite request something to literally roll your eyes at it seems like you're just a really anti-social person who considers any and all requests to be unreasonable. I didn't phrase my request particularly rudely or forcefully so your claim that I'm being rude and unreasonable is just plainly unfounded. I also told you that it's not the first time you've spammed my inbox like this so you can stop trying to act like I made my request over a single unnecessary notification email.

I've never operated a 99.999% uptime environment. I'm not really about that.

Well why do you then start going on about EEC memory, RAID arrays, backups and other things that are used in systems with very high uptime and low error rate demands? Do you really think I've never heard of any of those things?

SSDs tend to fail suddenly and catastrophically, whereas HDDs tend to give off warning signs and are often salvageable as they degrade. SSDs also have much worse data retention, for offline storage. Just FYI. And no, not everything I'm saying is intended to apply directly to your present situation.

Seriously, I already pointed out that I'm doing offline backups. As for HDDs failing, I've had enough of them fail catastrophically and suddenly due to mechanical issues to know that HDDs really don't fail much better ways than SSDs. My worst case was at a previous job where we lost a lot of really important system test data when two mechanical drives in a raid array failed catastrophically and suddenly in rapid succession.

Also, as I keep trying to tell you, if something doesn't apply to the use case being discussed then there's really no valid reason to bring it up. As much as you like to act all professional and stuff, I'm fully aware of everything you've brought up and have deliberately decided to ignore it as it's either superfluous to my use case or comes with unacceptable downsides.

I'd tell you to shut up about that superfluous crap, but you'd probably consider it to be on par with some obscenity laden tirade calling your mother a whore.