Igor

All flavours have identical hardware interface - if one doesn't work, others will also fail.

Did you try the image from my previous post?

There is no such overview - parameters can be different from kernel to kernel. Too much work for something almost nobody will notice. One parameter that is common for all is extraargs= which is directly translated to https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html Peek into boot.cmd script to understand how those parameters are passed on.
 
Then others - like verbosity - is just extracted from there. Then you have overlays and its parameters. That is different from kernel to kernel. Its directly tied to the hardware.

We need a reason to make patch releases  

We need a reason to make patch releases  

I the past few days I got several messages regarding this problem, even all corespondent knows that Armbian official policy only support images that are digitally signed. That is Armbian and its supported under those terms (make sure to read them before making more damages). Everything else you found floating on the internet you are using on your own risk. Why this topic? Since majority of R&D costs are covered from our private pockets (for official Armbian public share is between 0.2 and 0.4%),  most of your requests (for more of our private time/cash) can only ends in "f* off", "stop wasting our time", ... This is open source and "you", the one that need this and that function, full working and supported OS on every cheap garbage you purchase for a few bucks ... fork the code and maintain it! Armbian base maintenance (also source for TV boxes) currently costs us between 2.000 and 5.000 EUR per day and I have no idea how much people that fork this project adds that things also works (no idea how well) on TV boxes, that are similar to SBCs. If only 10% its already a lot! And what do they / we get back for that? Extreme constant demand and dissatisfaction since its absolutely not possible to fix all problems (for just 100 hours per day) and people doesn't (want to) understand that.
 
We - Armbian - doesn't want to do anything with our forks - focusing to single board computers represent an insane big project, which we have already have big troubles to keep up. This policy is present since ever and for several months we are trying at least to do something about. Many people were investing their precious time into the project "What to do with TV boxes" to make this clear, to find best relationship and perhaps also support important Armbian forks in some way. Project is again 99.9% covered from our private pockets.
 
If @balbes150 decided to stop supporting free of charge for you, for whatever reason, we have nothing to complain and I am sure we all fully support his decision but perhaps his Google translated words might scared you off. If he stop maintaining things, he is no longer responsible that boards breaks down. HW defects because of leaving off maintenance are extremely rare, but possible - I think he wanted to emphasize that. One doesn't need to add any evil code, hardware starts to break down when support is canceled, slowly but surely ... Besides, he is not to blame. Open source projects are done together - if you don't help him (and apparently you don't, with rare exceptions) and at least inspect and correct his work, why complaining and worrying about bad/evil code? Join development process and stop being cheap consumer who is complaining over the product he got for free.

Make sure to check his (and also our) code and also perhaps understand that he might need a full-time assistant(s) to roll things out at the present level. If not, why the fuck anyone complains? There is a fork button.
 
How to help improving things? https://www.armbian.com/get-involved/ The same way for TV Box Armbian fork.

Ok, I bought better SD card and now everything works great. Tank you!

I am also very happy that we manage to cover this purchase together in so little no time. This was also a live test of our crowdfunding system. It works surprisingly well and we will certainly use it for our other projects in the future.
 
As you already noticed, server was already purchased and is currently under evaluation. This upcoming release will already be build on it. We already built few nightly builds and speed bump from aging dual xeon is hard to describe  
 
Thank you all for showing us support!
 

Paypal donations and forum donations are not synchronised even paypal user would be the same  Sorting those things is yet another project, but at the project location it will remain at sight who supported server purchase. 

I am also very happy that we manage to cover this purchase together in so little no time. This was also a live test of our crowdfunding system. It works surprisingly well and we will certainly use it for our other projects in the future.
 
As you already noticed, server was already purchased and is currently under evaluation. This upcoming release will already be build on it. We already built few nightly builds and speed bump from aging dual xeon is hard to describe  
 
Thank you all for showing us support!
 

Paypal donations and forum donations are not synchronised even paypal user would be the same  Sorting those things is yet another project, but at the project location it will remain at sight who supported server purchase. 

I am also very happy that we manage to cover this purchase together in so little no time. This was also a live test of our crowdfunding system. It works surprisingly well and we will certainly use it for our other projects in the future.
 
As you already noticed, server was already purchased and is currently under evaluation. This upcoming release will already be build on it. We already built few nightly builds and speed bump from aging dual xeon is hard to describe  
 
Thank you all for showing us support!
 

Paypal donations and forum donations are not synchronised even paypal user would be the same  Sorting those things is yet another project, but at the project location it will remain at sight who supported server purchase. 

Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
 
Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.
 

It's a gaming case. Has all requirements such as leds in the bottom  , green led Razor logo in the front, glass window and RGB leds on the cooling cap ...  but it is fu* 1cm too small to mount a radiator inside the case.  I could mount it outside but its not screwed with all screws . Cooling performance is awesome at this point.
 
Ignore messy cabling - will be done at the end.
 

I already have BPI-P2-Zero device tree and kernel config ready. At least for board revision 1.1. The version 1.0 has some hardware issues and differences. My current test image is based on Yocto/OpenEmbedded. I plan to send DT upstream and then I want look how to build Armbian for this board.

@IgorArmbian_20.11.0-trunk.41_Odroidc2_focal_current_5.9.10.img did the trick. No hangs or death after apt upgrade and reboot!

I am almost certain you will run into the same problem on a X86 machine. Armbian is 100% compatible on userland level and OMV is a bulky suite which dramatically changes OS ... you can see OMV forums how to deal with those problems. IMO,  to be on a safe side, you will need to use the power of Docker. Armbian fully supports it for years.

Lately we made many enhancements on infrastructure but a lot of things are still WIP. Re-director stuck somewhere in the half-way - geolocation is planned since start but requires more work and and better testings. Before jumping ahead I would welcome you to check https://armbian.atlassian.net/browse/AR-444 and comment there (PM to me or @lanefu) for write access. Then we decide which part suits you best.
 
We will do the best to support you but sometimes it can take time - we all have daytime work and families and we are also just in the final round to push out a release. 
 
Welcome!

Hi all. 
I again had the pleasure of working with an amazing server. This time the AMD Threadripper 3990X, 64-cores and 128 threads.
After last week working on a 32-core ARM server I thought I had seen performance.

This is again not comparable with anything before.
 
I again got private SSH access. So I opened 3 terminals. One with HTop, another to check sensors. And the 3th to execute my benchmarks.
First thing I saw were the 128-threads. Being used to seeing 6, this was almost unbelievable.

With light loads it turbo's up to 4.3Ghz. All cores maxed out @ 3Ghz while consuming 400W.
Reaching a single core 7zip decompression score of 4545MIPS @ 4.3Ghz.
The Ampere 32-core ARM server at 3.3Ghz reached 2763.
This again shows the Ampere server doesn't use high performance cores. It doesn't perform great per clock.

Coming soon is a benchmark of an AWS server. This uses high performance cores based on the ARM N1 cores. A derivative of the A76.
This reaches 3393. This clocked at only 2.5Ghz. So this does perform better per clock. Do know this is comparing peers with bananas(don't want to confuse with apples).

And scoring 391809MIPS with 7zip multi-core decompression with default settings.

Then with an overclock to 3.9Ghz all cores it consumed +600W. With a 7zip decompression score of 433702MIPS
This is again so many levels better than the Ampere 32-core ARM server which got 85975MIPS. 32-cores of the AWS graviton2 does 110628.
So this AMD server is up to 5 x more powerful when overclocked, than the Ampere 32-core server. Consuming 6 x as much. 
With normal configuration they both perform almost as well in performance/watt.

In idle the Threadripper sonsumed 100W, what is a lot for doing nothing.
The 32-core ARM server only consumed a bit more than 100W maxed out. And about 20W in idle.

The BMW Blender benchmark, which takes 29m23s on the fastest ARM SBC the Odroid N2+. The Ampere ARM server did it in 8m27s.
For the Threadripper this was a way too light load, it did it in 30s. 

Even when doing this render 10 x after each other it didn't raise the temperatures much. The maximum I've seen was 50C.

To try a heavier load I downloaded the Barber Shop Blender render. This was 6912 tiles to render. But again the Threadripper wasn't impressed by this load. 2m18s79. The AWS with 32-cores (of 64) done this in 8m28s. So this ARM server does compete well per clock for a floating point task with TR.

ARM may be great, but AMD is mighty. Intel does not have anything to compete with this. Certainly not performance/watt. 
It was a pleasure benchmarking this server. 
I learned a lot, like that I need to find better tools for these amazing machines.  
 
The specs of this monster :
 
ASRock Rack TRX40D8-2N2T AMD Ryzen Threadripper 3990x 256GB memory (8 x 32Gb) ECC 2 x 1TB PCI 4.0 Nvme SSD Water Cooling  
The specs of the Threadripper 3990x
 
64-cores 128-threads AMD64 Zen2 Matisse 2.9Ghz - 4.3Ghz 4-channel DDR4-3200 MHz 256GB RAM 88 lanes PCIe4 TSMC's 7nm process node 280W - +400W 32 KB L1 per core (64x) 64 x 512 KB L2 256 MB L3 cache shared
You can see my full review video here, greetings.
NicoD

 

Lately we made many enhancements on infrastructure but a lot of things are still WIP. Re-director stuck somewhere in the half-way - geolocation is planned since start but requires more work and and better testings. Before jumping ahead I would welcome you to check https://armbian.atlassian.net/browse/AR-444 and comment there (PM to me or @lanefu) for write access. Then we decide which part suits you best.
 
We will do the best to support you but sometimes it can take time - we all have daytime work and families and we are also just in the final round to push out a release. 
 
Welcome!

At least people that work on development can mitigate this frustration when catching the bug or fixing the problem.
 
 
We just got ARM64 server on our hand as a donation from:
 


https://www.worksonarm.com/
https://github.com/WorksOnArm/cluster
 
but it will only be available for limited time and before we can use it in production, we need to port our build system to support native building, test and then start using it in production. 
 
 
Fastest build server we will need to purchase - we still need a major CPU upgrade on cross compilation server. Something in range of Threadripper 3970x / 3990x + board + pci4 ssd in raid0 + 128GB memory which will costs us ∼6000 EUR.
 
Our current aging 5 years old Dual Xeon E5-2683 build/CI server was also purchased with help from community and I hope we will also receive help!

Yes. Its around 100W on idle - it won't be put off - and 400W at full load. Not that bad.

We plan to hook several CI actions to it and perhaps provide one VM for developers. https://armbian.atlassian.net/browse/AR-538

I had many difficulties with a setup, hw and sw wise + daily workload - was totally exhausted. It was insane intense day  Fear and fatigue mixed with excitement. 
 
I did quick 7zip benchmark with slight load in the back so numbers are not very accurate:
 
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,128 CPUs AMD Ryzen Threadripper 3990X 64-Core Processor (830F10),ASM,AES-NI) AMD Ryzen Threadripper 3990X 64-Core Processor (830F10) CPU Freq: - - - - - - 512000000 - - RAM size: 257677 MB, # CPU hardware threads: 128 RAM usage: 28240 MB, # Benchmark threads: 128 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 265590 11420 2263 258367 | 4449269 12095 3139 379390 23: 158167 10527 1531 161153 | 4467139 12343 3133 386528 24: 120144 11304 1143 129179 | 4297484 12140 3108 377129 25: 104345 11827 1008 119137 | 4206512 12129 3088 374316 ---------------------------------- | ------------------------------ Avr: 11270 1486 166959 | 12177 3117 379341
What we need it for is awesome - it can rebuild kernels in no time. Only thing i recently measured was that it can assemble 194 images in 32 minutes (sadly i don't have exact number from previous server, but it was measured in hours) and it has more efficient cooling. It doesn't heat up much but it consumes around 100W more power than the previous one  In term of raw cpu power Passmark went from 24k -> 80k + a lot better IO due to raid 0 PCI4 nvme drives and faster memory.
 
@Werner @NicoD
 
I will give you access for a few days, then its erased and goes into the real function, where access under certain conditions will also be possible - we are discussing terms here https://armbian.atlassian.net/browse/AR-538

It's a gaming case. Has all requirements such as leds in the bottom  , green led Razor logo in the front, glass window and RGB leds on the cooling cap ...  but it is fu* 1cm too small to mount a radiator inside the case.  I could mount it outside but its not screwed with all screws . Cooling performance is awesome at this point.
 
Ignore messy cabling - will be done at the end.
 

Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
 
Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.
 

Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
 
Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.
 

Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
 
Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.