Shimon

@balbes150 About the `dd_backup_x` script - it already hardcodes `pv` as a reqirement, so there's no reason not to use `pigz`, if present at least, for better performance .

As @tkaiser mentioned elsewhere, there's currently a great bargain on Chiptrip Q8 at GB. Libreelec already runs on Ugoos UT3+, and with Linux support bound to improve in the coming months, this looks very attractive. Great minds think alike, eh @mdel?

Could any Alfawise H96 Pro+ users run the phoronix ramspeed benchmark? It'd be interesting to know if you could tell DDR4 versions from the DDR3 ones without opening the case PM me if you need help running the suite.

Do they include the A/V (3xRCA) output on Linux? Amdahl's law is such a bitch on ARM though, it should definitely make some difference in single-threaded scenarios.

Yup, that's the plan! Any plans on updating the vegas95 images? I'm also curious if the composite A/V output is supposed to work on Linux? I'd already asked about overclockability of that kernel but forgot the modified binary blob allowing one to achieve over 1.6 Ghz might be Odroid specific. Can you confirm it's even doable?

I'm going to test the Linux network performance of two different S905 GigE boxes next month so we'll be able to compare results.

S905x doesn't support 1000M period, look at the Amlogic schematics. That makes S905 superior in that single area but S905x compensates with the addition of crypto instructions.

That probably means you're using the universal 3.14.29 kernel whereas the original dtb's are supposed to work with 3.14.79 Vega kernel for S905 devices. But yeah, definitely a bug as both types of images work fine on my S905 based boxes.

@balbes150 What happened to `zram` support in the 3.14.79 kernel from VegaS95 20170125? It seems to be compiled in instead built as a module, and doing the following doesn't work for me: # echo 1 > /sys/block/zram0/reset // OK # echo 4096M > /sys/block/zram0/disksize // bash: echo: write error: Invalid argument Any ideas? Other images work fine via the zram kernel module. edit: Missed the kernel message: zram: Cannot initialise lz4 compressing backend and the only way to make it work is to change back to lzo first, etc. Definitely not right! # echo lzo > /sys/block/zram0/comp_algorithm

OK, I've found the culprit. VESA modes do work fine, indeed. For some reason, adding additional commands to my rc.local after the /boot/vegas95_init.sh invocation, interfered with setting the resolution somehow.

Are you sure it's supposed to work? I was using the Armbian_5.24_Vegas95_Ubuntu_xenial_3.14.79_20160125 image for this test and it ends up with no console, as described. Moreover, you didn't include the dtb file for Mini MX III which was present in the github repo last year. I had to use a local copy.

@balbes Are the VESA modes from vegas95_init.sh meant to be used in s905_autoscript.cmd or is that some generic armbian stuff? I ended up with green screen and no visible console trying to set 1280x1024p60Hz

Forgot to mention, iotop stopped working (IIRC): Could not run iotop as some of the requirements are not met: - Linux >= 2.6.20 with - I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING)

That's 1536 actually, never mind what the evil blob says. http://forum.odroid.com/viewtopic.php?p=157441#p157441

Interesting! Looks not too hot @50°c, so provided you were on performance governor, this could either mean the 4-core baseline was slightly worse on that box or the benchmark doesn't scale at these settings.

Yeah, that's more or less it on a S905X. If you shut the X server down, like: sudo service lightdm stop you should be able to achieve peak performance.

Look at my comment #133 - the command is meant to run inside the c-ray-1.1 directory after compilation. If you ran the benchmark at least once, the c-ray-mt binary should be found there.

Could you try running the renderer for a few minutes? e.g: ./c-ray-mt -t 32 -s 1900x1400 -r 8 -i sphfract -o output.ppm It takes 254 seconds on my MiniMX III (S905) so unless S912 starts overheating it should complete the same task in about 152s.

Thanks @balbes150! The results (7992 vs 4781) do indicate perfect scaling. In other words, as long as there's no thermal throttling, S912 really seems to offer 66% more computing power. Not bad for a $50 box

OK then, a quick test to see what DVFS thinks about this idea: echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor wget http://www.phoronix-test-suite.com/benchmark-files/c-ray-1.1.tar.gz tar xf c-ray-1.1.tar.gz cd c-ray-1.1/ gcc -O3 -mcpu=cortex-a53 -o c-ray-mt c-ray-mt.c -lm -lpthread && ./c-ray-mt -t 32 -s 320x240 -r 8 -i sphfract -o output.ppm cd Anything better than `7 seconds (7437 milliseconds)` will have meant more than 4 cores can be utilised at once. (gcc 5.4 required for an apples to apples comparison) In case it does work, something like e.g. `-mtune=cortex-a57.cortex-a53` can be added to the gcc command line to enable big.little optimisations.

S912 is a big.little setup so unless you can confirm the kernel supports heterogeneous multi-processing, it definitely won't make any difference. In other words the kernel's .config must contain: CONFIG_SCHED_HMP=y but even then we still have no idea what the firmware is capable of.

OK then, no surprises here - thanks for trying

@balbes150 Did you confirm anything over 1.5 GHz was actually real by benchmarking?

Try this for a start: echo 2000000 | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

@clarkss12 You didn't test any higher frequencies, DUH!