Debian vs. Ubuntu on NanoPi NEO

[rupy]

What are the differences between Debian and Ubuntu servers from armbian?

 

When is the Debian server release coming for the NanoPi NEO?

[tkaiser]

When is the Debian server release coming for the NanoPi NEO?

 

When we're ready with testing -- especially DRAM needs a lot of ressources since this is the first H3 device we deal with with a single bank DRAM configuration already showing higher consumption figures compared to the small Orange Pis.

 

Difference between Ubuntu and Debian? Well different distributions they are, our build system is able to debootstrap based on both so we usually provide both images.

 

BTW: I don't know why Igor prepared the download page with a Xenial image already without writing in red letters 'Preliminary! Only a test version!' on the download page

[Igor]

BTW: I don't know why Igor prepared the download page with a Xenial image already without writing in red letters 'Preliminary! Only a test version!' on the download page

 

Added. I hope it will be noticed and cut down unnecessary questions.

 

@rupy

We just got the boards a week / days ago and only some basic testing were done.

[tkaiser]

@rupy

We just got the boards a week / days ago and only some basic testing were done.

 

And first test results don't look that promising

 

I get 470 mW difference on the 512MiB model when switching between 132 MHz and 672 MHz DRAM clockspeed when being idle (OPi Lite just 305 mW difference) and temperatures are also affected (+9°C difference w/o heatsink, no idea regarding OPi Lite). And the largest increase in consumption is between 408 MHz (lower clock limit with unmodified BSP kernel) and 432 MHz (the value FA chose) so I wonder why they chose 432 MHz when using 408 MHz makes no difference performance-wise but saves another 140 mW?

 

Then I have u-boot hangs on various NEOs and on the 256 MiB model console gets flooded with obscure USB error messages. Next tests scheduled over the next days:

• Walking through all DRAM clockspeeds and running/logging tinymembench results to a file
• testing heat behaviour (overheats badly compared to Oranges)
• testing lima-memtester (with Mali enabled in fex and setting DRAM clockspeed from userspace), this will require patched kernel and setup with heatsink and fan
• In case DRAM clockspeeds above 432 MHz tend to be unreliable testing relationship between DRAM clockspeed and u-boot hangs (we use M1 defconfig and this sets DRAM clockspeed to 624MHz, also we use wrongly SY8106A settings there)

EDIT: Switching instantly between 132 MHz and 672 MHz DRAM clockspeed pretty reliably deadlocks the board, DRAM clockspeed changes should happen in small intervals

[rupy]

Ok, I have 3x Orange Pi ONE's running Armbian since they came out... zero problems.

 

I also bought 3x NanoPi NEO's, will try to boot one with the Xenial image to test later tonight.

 

Thanks for the heads up and awesome work!

[rupy]

Ok, so tested with my own benchmark: https://github.com/tinspin/rupy/wiki/Comet-Stream

 

And it runs a little hotter than the Orange Pi ONE, how much I don't know, what is the command to measure the temperature on this thing?

 

But one component in particular is suuuuper hot: it't the tiny five legged black rectangle that reads A401 right next to the memory.

 

It's >100C at least... burns like hell. And more worryingly so it burns no matter the load... so I'll turn it off now...

[zador.blood.stained]

But one component in particular is suuuuper hot: it't the tiny five legged black rectangle that reads A401 right next to the memory.

 

It's >100C at least... burns like hell. And more worryingly so it burns no matter the load... so I'll turn it off now...

U7? That is an LDO voltage regulator that provides 1.2V for various SoC parts and 1.1V for EPHY SoC part.

Maximum consumption output current for this regulator is 500mA. For comparison, OPi Lite uses buck converter rated up to 2A.

[rupy]

Yep, that's the one. So that can't be fixed from software, guess this board is showing up to be a dud. I'm almost thinking of going back to RPi 2! At least the britts know their power circuits!

[tkaiser]

At least the britts know their power circuits!

 

They don't

 

Remember the 1st gen Raspberries? Using an LDO voltage regulator to provide 3.3V wasting 700 mW doing NOTHING except heating up the environment (700 mW comparing RPi B with B+). LAN9512 overheating like hell since they f*cked up powering scheme and sometimes this chip tried to provide 1.8V to the SoC?

 

Think about why there are still 'Raspberry Pi heatsink sets' available consisting of 3 heatsinks where only one might be necessary for RPi 2 or 3: Since power circuitry was an absolute fail on their first try.

 

And please remember: Those britts invented the most shitty idea ever: powering devices that need more than 50mA through Micro USB. It's simply their fault that so many SBC are that unreliable since vendors thought 'Hmm... we know that Micro USB to power something reliably is crap... but since the RPi people did it and customers demand... let's sell them crap' 

 

But I fear I have to agree regarding NEO. Based on first tests NanoPi NEO is only made for lightweight jobs. I managed to deadlock the board running lima-memtester with just 408 MHz DRAM clockspeed within 2 minutes (now using an annoying fan it's still running with DRAM clocked at 672 MHz). Also not a single disk spinned up when connected to NEO. This board is not made for heavy stuff, unfortunately it's not that energy efficient either.

 

EDIT: The physically exposed USB port on NanoPi NEO is usb3 and not usb1 as assumed. Therefore it was due to my fex settings that no disk was spinning up since all the disks I tried got only power through the USB port but no data connection since I had usb3 disabled in fex file. With usb3 being active at least a quick test with an SSD looks ok.

[rupy]

Ok, after testing the board for a long time and getting the temperature with:

 

cat /sys/class/thermal/thermal_zone0/temp

 

It seems NEO is actually cooler than the ONE!

 

~60C vs ~70C

 

I'm going to leave it benchmarking for the night.

 

As for how long this thing can run I guess only time will tell...

[rupy]

This board is not made for heavy stuff, unfortunately it's not that energy efficient either.

 

After one night of benchmarking I must disagree.

 

To broadcast 100.000.000 messages over HTTP without a single miss at 650 messages/joule/$ (which is the highest to date) is not bad for something this small/silent/light.

 

Longevity and SD bus remains to be tested though...

[tkaiser]

To transfer 100.000.000 messages without a single miss at 650 messages/joule/$ (which is the highest to date) is not bad for something this small/silent/light.

 

Good to know. And please remember: That's just settings (NEO uses different ones than OPi One). NEO's hardware is not that energy efficient (idles with identical settings ~300mW above an OPi Lite!) but on the NEO image we use a few settings that help a lot with energy savings. I'm currently fine tuning these settings, will test the images and provide later a patch.

 

Based on your workload (no idea what these messages are you're talking about) an OPi One, OPi PC or OPi Plus 2E would get better messages/joule/$ ratings.

[rupy]

You can see the comparison table and download source here: https://github.com/tinspin/rupy/wiki/Comet-Stream

[tkaiser]

You can see the comparison table and download source here: https://github.com/tinspin/rupy/wiki/Comet-Stream

 

Well, it's still unclear to me where the performance bottlenecks of this setup are. CPU horsepower, memory throughput/latencies, IO bandwidth and network throughput/latencies are different areas to consider.

 

Given your workload is bottlenecked by Fast Ethernet switching to OPi Plus 2E might greatly improve messages/joule/$ ratings. Memory throughput obviously doesn't matter at all since on your charts OPi One and NanoPi NEO perform identical while their DRAM performance differs drastically. If you use default settings then OPi One is almost twice as fast regarding memory throughput compared to NEO (standard memcpy: 890 vs. 435 MB/s). Things that matter are: dual bank vs. single bank configuration and different default DRAM clock.

 

So by using improved NEO settings with your Orange Pis ONEs they will clearly outperform NEO when it's about messages/joule/$

 

Simply compare what changes between One and NEO in fex files (HDMI/Mali disabled, downclocking DRAM to 408 MHz to name the two most important changes) and keep in mind that NEO's hardware wastes more energy than One/Lite with same settings. More details here http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/?view=getlastpost

[rupy]

Ok, well I doubt memory will be the bottleneck.

 

You have SD card and CPU blowing up in flames way before the RAM becomes an issue specially with 512MB.

 

I think these small computers are surprisingly well balanced to become part of distributed HTTP server solutions!

 

With that I mean that 100Mb/s, H3, SD card and 512MB RAM are all about the same place if you write minimalist software.

 

We'll see how it turns out.

 

btw, thx for second release and jessie!

[tkaiser]

Ok, well I doubt memory will be the bottleneck.

 

Last answer here: It's not about believing it's about active benchmarking.

 

It really depends on how your application is bottlenecked to choose the right device.

 

As an example: sysbench's cpu test is used everywhere. Mostly by people who don't understand the difference between synthetic benchmarks and real world workloads. Sysbench is just calculating prime numbers and therefore not dependant on IO, L2 cache or DRAM access speeds. It's a pretty good example for a benchmark that does not translate well to real world workloads.

 

Let's take cpuminer as another example. This is a bitcoin miner being able to use NEON instructions on ARM that speed up things a lot. But cpuminer's performance relies heavily on DRAM clockspeed. So when you compare a NanoPi NEO (single bank DRAM configuration and 432 or 408 MHz DRAM clockspeed) with an Orange Pi One/Lite (dual bank configuration, 624 MHz DRAM clockspeed, lower idle consumption) then NanoPi NEO with active cooling will get 1.83 khash/sec running with 1200 MHz while an Orange Pi One or Lite achieves 2.11 khash/sec at the same CPU clockspeed simply using a different DRAM config.

 

Add to this the higher ground consumption of NanoPi NEO and 'performance per watt' ratio of OPi One/Lite might be over 1.5 times better compared to Nano Pi NEO. While you won't see any performance difference when running sysbench and 'performance per watt' difference will be therefore lower -- maybe 1.2.

 

It depends on the type of software you use and default settings. With Armbian we currently provide low power settings only for NanoPi NEO. Simply by adopting these improvements for Orange Pi One this device will outperform every NanoPi NEO. Both regarding maximum performance (due to different DRAM config and better throttling behavour when only passive cooling is used) and especially 'performance per watt' numbers (since you can lower ground consumption with Oranges a lot more compared to Nanos). This is where Armbian really shines: improved settings so the hardware performs better.

[rupy]

Ok, gotcha.

 

Are these low power settings enabled by default?

[rupy]

So does the NEO 2 have the same problems?