tkaiser

Yes, on my UP Board I also had to adjust thermal source by hand (6 different sysfs nodes, I symlinked the most appropriate to /etc/armbianmonitor/datasources/soctemp). Thank you for the output! Interesting results: your Atom is allowed to clock at up to 1920 MHz but if all 4 cores are busy max cpufreq gets reduced to 1680 MHz. What is this for a device exactly?

Unfortunately I have not the slightest idea what you're talking about. My goal is to avoid shitty fans and fansinks and if boardmakers start to improve this is possible.

Now the same excercise with RockPro64. First test is with board lying flat on a table with tall heatsink using Pine's gray thermal pad (BTW: same height as FriendlyELEC's), I used ayufan's latest release image (still using 1.8/1.4 GHZ max) and 'sbc-bench.sh -T 70 ; sbc-bench.sh -t 50' 16:39:42: 1800/1416MHz 6.11 100% 0% 99% 0% 0% 0% 83.3°C 16:39:54: 1800/1416MHz 6.09 100% 0% 99% 0% 0% 0% 83.9°C 16:40:06: 1800/1416MHz 6.08 100% 0% 99% 0% 0% 0% 82.8°C 16:40:18: 1800/1416MHz 6.13 100% 0% 99% 0% 0% 0% 84.4°C 16:40:30: 1800/1416MHz 6.18 100% 0% 99% 0% 0% 0% 83.9°C Throttling statistics (time spent on each cpufreq OPP) for CPUs 4-5: 1800 MHz: 300.11 sec 1608 MHz: 0.14 sec 1416 MHz: 0 sec Just a little throttling occured at the end of the benchmark (thermal trip point in DT defined as 85°C) Next test with thermal pad replaced by copper shim of same height and board still lying on the table: 17:11:54: 1800/1416MHz 6.12 100% 0% 99% 0% 0% 0% 70.6°C 17:12:06: 1800/1416MHz 6.10 100% 0% 99% 0% 0% 0% 71.1°C 17:12:18: 1800/1416MHz 6.09 100% 0% 99% 0% 0% 0% 72.2°C 17:12:30: 1800/1416MHz 6.13 100% 0% 99% 0% 0% 0% 73.9°C 17:12:42: 1800/1416MHz 6.11 100% 0% 99% 0% 0% 0% 72.2°C No throttling and max temperature reported as 74°C. Now bringing the board in an upright position trying to increase ventilation around the board: 17:54:53: 1800/1416MHz 6.09 100% 0% 99% 0% 0% 0% 70.0°C 17:55:05: 1800/1416MHz 6.21 100% 0% 99% 0% 0% 0% 70.0°C 17:55:17: 1800/1416MHz 6.17 100% 0% 99% 0% 0% 0% 69.4°C 17:55:29: 1800/1416MHz 6.20 100% 0% 99% 0% 0% 0% 71.1°C 17:55:42: 1800/1416MHz 6.17 100% 0% 99% 0% 0% 0% 71.7°C No throttling and max temperature reported as 72°C By simply replacing the thermal pad with a copper shim + thermal compound and otherwise identical environmental conditions (lying flat on a surface and ambient temperature around ~26°C) we get 11°C less and no throttling at all even with demanding workloads. @TLLim and @mindee: IMO that's something to consider for next batch of boards and heatsinks: try to save those inefficient thermal pads and allow for direct contact between heatsink and SoC with thermal paste. Without copper shim in between heat transfer should be improved even more. Almost forgot: Of course thermal pads also have an advantage: they stick pretty good to both heatsink and SoC and therefore are the better choice if the board is exposed to vibrations compared to a copper shim 'held in place' with a little bit of thermal paste. On the other hand I also have thermal glue somewhere around so that would be the next test (with NanoPi M4 once the board arrives).

Latest sbc-bench version 0.6 implements a new 'thermal testing' mode: root@nanopct4:/home/tk# sbc-bench.sh -h Usage: sbc-bench.sh [-c] [-h] [-m] [-t $degree] [-T $degree] ############################################################################ Use sbc-bench.sh for the following tasks: sbc-bench.sh invoked without arguments runs a standard benchmark sbc-bench.sh -c also executes cpuminer test (NEON/SSE) sbc-bench.sh -h displays this help text sbc-bench.sh -m [$seconds] provides CLI monitoring (5 sec default interval) sbc-bench.sh -t [$degree] runs thermal test waiting to cool down to this value sbc-bench.sh -T [$degree] runs thermal test heating up to this value ############################################################################ root@nanopct4:/home/tk# This mode makes only use of cpuminer and is only useful to measure thermal effects (looking at temperatures, cpufreq statistics and relative performance differences) but provides no general benchmarking functionality other than displaying thermal efficiency of physical aspects of heat dissipation (heatsink, heatsink + fan, nothing, airflow, enclosure or not, whatever) efficiency of throttling settings (bad settings --> bad performance once throttling occurs) Both -t and -T need an integer value as second argument: e.g. '-t 50' or '-T 70'. In the former case sbc-bench ensures that SoC temperature falls below 50°C prior to starting the test, the latter case will result in the tool heating up to 70°C first and then starting the test. Both modes should be used combined to generate a reproducable environement. E.g. sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 This will result in a first test heating up the SoC to 70°C, then testing, then let the second run wait to cool down to 50°C before 2nd test starts. This way it's ensured that several tests run under almost identical conditions. If you want to skip pre-heating or waiting for chill down simply use -T with a very low value, e.g. 'sbc-bench -T 20'. As an example comparison of NanoPC-T4 with stock heatsink. 1st test with FriendlyELEC's blue thermal pad between RK3399 and heatsink, 2nd time with the thermal pad replaced by a copper shim with thermal paste (test duration is ~302 seconds). With thermal pad: 1992 MHz: 100.79 sec 1800 MHz: 0.02 sec 1608 MHz: 0 sec 1416 MHz: 169.13 sec 1200 MHz: 32.26 sec vs. copper shim: 1992 MHz: 136.00 sec 1800 MHz: 0 sec 1608 MHz: 0.02 sec 1416 MHz: 159.06 sec 1200 MHz: 7.19 sec Copper shim + thermal paste performs better but not that much in this mode (somewhat simulating the board being enclosed and idling at around 50°C). And it's also obvious that there's something seriously wrong with our throttling settings since 1800 and 1608 MHz cpufreq OPP are skipped. When those would be used performance in throttling state would be a little bit better. That's what the '-T' switch is about: operating the board under conditions where thermal trip points and such stuff can be tested efficiently.

Ugly hack but should work. Did you run into other issues with M4 so far? Different DRAM type seems to be no problem yet, right?

IMO it's worth to mention that it does work at all (see Igor and me spreading BS). Some sort of a status map with info on which board families such 'multimedia' features already work with links to forum threads with details should IMO be sufficient.

Results: http://ix.io/1lzW -- comparing with my previous run without modifying dmc policy: http://ix.io/1lkG So looking at dmc memory governor with dmc_ondemand we have 5870 7-zip MIPS and with performance it's above 6500 (I need to retest with fan). Individual results: A53 dmc_ondemand performance memset 1417.3 1413.7 memcpy 4784.5 4786.8 single latency 381.0 207.5 dual latency 451.9 240.6 7-zip single 837 1037 A72 dmc_ondemand performance memset 2809.3 2821.2 memcpy 4893.0 4895.7 single latency 381.7 217.8 dual latency 483.8 260.5 7-zip single 1336 1712 While memory bandwidth doesn't differ between both governors latency is highly affected. Same with single threaded 7-zip runs and also multi-threaded to a lesser extent.

Yes, you're right. By looking at dmc stats we might get the culprit: root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat trans_stat From : To :200000000300000000400000000528000000600000000800000000 time(ms) *200000000: 0 0 0 0 0 14 224442114 300000000: 8 0 0 0 0 0 2062 400000000: 0 6 0 0 0 1 11499 528000000: 1 1 5 0 0 0 25918 600000000: 0 0 0 0 0 0 0 800000000: 5 1 2 7 0 0 136407 Total transition : 51 This is NanoPC T4 running tinymembench: root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat cur_freq 200000000 Now repeating the test after: root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# echo performance >governor root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat cur_freq 800000000

After latest commit the output should be much better on Arch/Manjaro and localized systems. In case you want to try it again please provide iostat utility first via installing sysstat package (always helpful): pacman -Syu sysstat

Didn't know that. Maybe it's a good idea to summarize the status of these FAQs somewhere below docs.armbian.com?

That's pretty interesting. Can you please provide the output of the following: uname -a /usr/local/src/mhz/mhz 3 1000000 find /sys -name cpufreq Is it possible to easily rebuild the kernel on Manjaro? All the cpufreq stuff is missing (most probably not for a reason -- we consolidated this just recently in Armbian)

Good. Already prepared a bunch of copper shims of varying height and thermal paste since I would believe a lot of the poor thermal performance is due to heat not efficiently transferred into the heatsink. Curious when my M4 will arrive...

Hmm... that's a bit underwhelming. I had hoped for better results (even taking into account the 29°C ambient temperature). Do FE guys again use the blue thermal pad that is 1mm thick? And as already reported: throttling needs some tuning since we currently jump between 2.0 and 1.4 GHz and skip the OPP in between: 1992 MHz: 3949.34 sec 1800 MHz: 0 sec 1608 MHz: 0 sec 1416 MHz: 35.42 sec 1200 MHz: 0 sec Had no time to look into yet (too busy with a boring VoIP project these days)

For some use cases they do matter but unfortunately some users prefer questionable 'benchmarking' methods and ignore the importance the block size makes when accessing storage. That's why common tools like hdparm, dd and pv all simply suck when it's about to determine maximum storage performance or insights in general: SBC users seem to not want to accept most simple facts: testing with hdparm is always wrong since it uses just 128k block sizes when reading from disk. 128k were a sufficient number last century when the defaults were defined since back then the fastest HDD storage was slow like hell. Today it's just a joke to test with 128k. testing with pv is always wrong when not using -B switch (which no one does) since buffer size will then be calculated dynamically [1] and you get random numbers testing with dd can result in 'good' numbers if dd flags and block size has been set accordingly. Problem is: Usually these informations are not shared when dd 'benchmark' numbers are published so you simply not know whether testing was correct or just the usual 'benchmarking gone wrong'. That's why looking at dd numbers is almost always useless [1] quoting pv manual page: -B BYTES, --buffer-size BYTES Use a transfer buffer size of BYTES bytes. A suffix of "K", "M", "G", or "T" can be added to denote kibibytes (*1024), mebibytes, and so on. The default buffer size is the block size of the input file's filesystem multiplied by 32 (512KiB max), or 400KiB if the block size cannot be determined.

Yeah, your only option is https://h3droid.com then (Android 4.4 IIRC). Also IIRC Allwinner provided a newer Android for their old H3 SoCs which also requires a newer 'BSP' based on a smelly 4.4 kernel lacking DVFS capabilities. So pretty much unusable on those Orange Pi with sophicticated voltage regulation. TL;DR: Forget about Allwinner. To my (very limited) knowledge if it's about Android and consuming movies your best choice would be a cheap Amlogic TV box with a recent SoC. Or Rockchip. But honestly neither know nor care.

Youtube 'in the browser' works almost nowhere in Linux on ARM. And that's nowhere related to GPU but a VPU thing (GPU in the ARM world is 2D/3D acceleration, VPU does all the video HW acceleration -- every SoC vendor has its own video engine and therefore browser support is not widely existing in Linux -- Android is a different story and IMO your only option with these boards). I know of one platform where you can watch video smoothly in Chromium on Linux but this platform sucks in almost all other areas too much (limited to 800 MB DRAM for Linux, shipping with braindead defaults like no memory compression and swap on SD card and all such weird things) Further readings: https://forum.armbian.com/topic/8043-orange-pi-one-general-performance-browser-performance/ (Chromium + plugin on RPi might work) https://www.cnx-software.com/2018/08/24/nanopi-m4-raspberry-pi-rk3399-board/#comment-555726 (why 'Desktop Linux' always sucks)

Thank you but Jean-Luc from cnxsoft answered my question already one year ago: https://forum.armbian.com/topic/4854-add-support-for-rk3399-2xa724xa53/?do=findComment&comment=40088 RK3399 is RK3399, the only things that matter wrt board support are $someone providing a proper hardware description (device-tree these days) and in extreme cases special boot BLOBs (for DRAM initialization and such stuff). If this $someone is neither SoC nor board vendor (as in the case of Orange Pi RK3399) unfortunately you're on your own. None of the developers ever got an Orange Pi RK3399 dev sample and in the meantime even some people spread the rumour this board will be discontinued (neither know nor care, I never understood the OPi RK3399 concept)

Picture courtesy of TL Lim. Check #Rock64 channel from yesterday here: http://irc.pine64.uk/

BTW: I asked yesterday TL Lim about thermal 'performance' of their new Graphene heatsink and he provided the following numbers using sbc-bench (all the time running an Ubuntu Bionic arm64 userland): No heatsink at all: Throttling occured already with multi-threaded 7-zip bench: 1800 MHz: 1803.60 sec 1608 MHz: 111.77 sec 1416 MHz: 185.81 sec 1200 MHz: 0.02 sec 1008 MHz: 0 sec Slim Graphene heatsink: Throttling occured when running cpuminer: 1800 MHz: 1863.62 sec 1608 MHz: 125.87 sec 1416 MHz: 8.82 sec 1200 MHz: 0 sec Mid profile heatsink: No throttling, SoC temp when running cpuminer up to 80°C Tall heatsink: No throttling, SoC temp when running cpuminer up to 74°C As expected the taller the heatsink the better the effect. TL also mentioned that the Graphene heatsink was tested in a condition with no airflow around and that it would perform significantly better when there's some airflow. Would be interesting how this heatsink performs with some air blowing laterally over the surface. As a comparison thermal performance of NanoPC-T4 with stock heatsink (but in different environment, using Debian Stretch, with 2.0/1.5GHz cpufreq OPP already enabled and higher throttling treshold): Throttling occured while running cpuminer: 1992 MHz: 3016.74 sec 1800 MHz: 0.14 sec 1608 MHz: 1.07 sec 1416 MHz: 263.46 sec 1200 MHz: 21.52 sec 1008 MHz: 0 sec It's obvious that NanoPC-T4 settings need some attention since the intermediate 1.8 and 1.6 GHz steps aren't used which makes throttling rather inefficient. Also benchmark execution lasted way longer and some results are below RockPro64 numbers while they should be higher due to higher cpufreqs so we need to look into this in more detail. Finally a thermal image of RockPro64 under full load without heatsink showing how efficient heat dissipation into the ground plane works (the PCB itself acting as giant heatsink):

Only that there's no filesystem corruption. Running out of ideas other than trying now memtester as next step. Still there was a kernel oops before in armbianmonitor -u output so there's something wrong: [ 27.860507] Unable to handle kernel NULL pointer dereference at virtual address 00000052 [ 27.869636] pgd = ecfc4000 [ 27.869642] [00000052] *pgd=00000000 [ 27.869663] Internal error: Oops: 5 [#1] SMP THUMB2 [ 27.869668] Modules linked in: sun4i_gpadc_iio snd_soc_simple_card snd_soc_simple_card_utils snd_soc_spdif_tx evdev ir_lirc_codec lirc_dev sun4i_codec sun4i_spdif snd_soc_core sun4i_ts sunxi_cir snd_pcm_dmaengine snd_pcm pwm_sun4i nvmem_sunxi_sid sun4i_gpadc snd_timer snd soundcore sun4i_ss uio_pdrv_genirq uio bonding hidp rfcomm bluetooth ecdh_generic brcmfmac brcmutil cfg80211 rfkill ip_tables x_tables pwrseq_simple realtek [ 27.869753] CPU: 0 PID: 1054 Comm: (rc.local) Not tainted 4.14.14-sunxi #1 [ 27.869756] Hardware name: Allwinner sun7i (A20) Family [ 27.869760] task: ec875100 task.stack: ec856000 [ 27.869774] PC is at rwsem_optimistic_spin+0x94/0xd0 [ 27.869786] LR is at rwsem_down_write_failed+0x4f/0x1dc [ 27.869790] pc : [<c0154398>] lr : [<c0878bb7>] psr: a00e0133 [ 27.869793] sp : ec857ce8 ip : c9fa244c fp : c9ef99a0 [ 27.869796] r10: c0ddda12 r9 : c0d03f48 r8 : c0e264a0 [ 27.869800] r7 : 00000001 r6 : ec857d04 r5 : ffff0001 r4 : ed00726c [ 27.869804] r3 : fffffffe r2 : 00000000 r1 : 00000000 r0 : ed00726c [ 27.869810] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [ 27.869814] Control: 50c5387d Table: 6cfc406a DAC: 00000051 [ 27.869818] Process (rc.local) (pid: 1054, stack limit = 0xec856210) [ 27.869823] Stack: (0xec857ce8 to 0xec858000) [ 27.869831] 7ce0: ed00726c ffff0001 ec857d04 c0878bb7 00000000 ee4d1f00 [ 27.869840] 7d00: c9ef9fc0 00000001 ec857d04 ee4d1d00 ec801ba0 c0206685 ec82675c b8d7949c [ 27.869849] 7d20: 00000100 ed00726c ec801820 ed007268 ec826b7c c0e264a0 ec826b40 c0ddda12 [ 27.869857] 7d40: c9ef99a0 c0878399 ec801640 c0206605 c0a6bf24 ed018474 ec875100 ec826b40 [ 27.869866] 7d60: ec826060 b6904000 ec857db4 00002000 00000000 ecd498b4 00000001 c01fd345 [ 27.869874] 7d80: b6904000 c01fe51d 00000000 ecf32b40 00000000 c0d03f48 c9fa7b00 ec864380 [ 27.869882] 7da0: eccd1600 c0202bf7 00000000 00000000 00000000 ec864380 00000001 00000000 [ 27.869891] 7dc0: 00000000 ffffffff c0df61dc c0117fc9 000003f3 00000400 ed86f000 00000700 [ 27.869899] 7de0: 00000000 b8d7949c eccd1600 ec864380 ec864380 edbd4700 c9fa7b00 b8d7949c [ 27.869908] 7e00: ec864380 ec864380 edbd4700 c0117fd7 000003f0 0000021c ec864380 c022df6f [ 27.869917] 7e20: b8d7949c ecd49880 c0d03f48 c9fa7b00 6474e551 ec857e48 eccd1600 ecd498b4 [ 27.869925] 7e40: 00000001 c026b021 00000000 ec857e40 00000001 c9efc2c0 c9f933c0 c9fa7e00 [ 27.869933] 7e60: 00000080 c0d03f48 00000000 00000000 00000000 b8d7949c 00000002 00000080 [ 27.869942] 7e80: 00000001 c9f93548 00000000 ed067350 00000080 c0a6ea28 00000034 00000000 [ 27.869950] 7ea0: 00000000 00000000 ed067350 ffffe000 ec856000 b8d7949c 00000000 c0d2594c [ 27.869959] 7ec0: c9fa7b00 c0e28b74 fffffff8 c0d228f4 c0e28b74 c0a6ea28 00000002 c022e1d3 [ 27.869967] 7ee0: b8d7949c c9fa7b00 c0d03f48 c0e28b74 fffffff8 c0d228f4 c0e28b74 c0a6ea28 [ 27.869976] 7f00: 00000002 c0269e59 c9fa7b00 c9fa7b0a c9fa7b02 b8d7949c c0d25930 c0d25930 [ 27.869985] 7f20: c9fa7b00 c022e1d3 c0d0d560 c0d03f48 ec875100 ed8fa000 ffffe000 01bfa718 [ 27.869993] 7f40: c9fa7b00 00000000 0000041e c022eae5 0000041e edbd4700 edbd4738 00000000 [ 27.870001] 7f60: 00000000 b8d7949c 00000000 00000000 01c0a380 01bfa718 0000000b c0106824 [ 27.870010] 7f80: ec856000 00000000 be96d6d0 c022edc1 00000000 01b0377c 01b85268 01c423a0 [ 27.870019] 7fa0: 00000000 c0106621 01b85268 01c423a0 01b182d8 01c0a380 01bfa718 01bf3200 [ 27.870027] 7fc0: 01b85268 01c423a0 00000000 0000000b ffffffff 01c0a380 00000000 be96d6d0 [ 27.870036] 7fe0: 0054998c be96d4e4 004a9333 b6bd7766 20010030 01b182d8 6fffd861 6fffdc61 [ 27.870056] [<c0154398>] (rwsem_optimistic_spin) from [<c0878bb7>] (rwsem_down_write_failed+0x4f/0x1dc) [ 27.870070] [<c0878bb7>] (rwsem_down_write_failed) from [<c0878399>] (down_write+0x41/0x44) [ 27.870084] [<c0878399>] (down_write) from [<c0206605>] (unlink_anon_vmas+0x75/0x168) [ 27.870100] [<c0206605>] (unlink_anon_vmas) from [<c01fd345>] (free_pgtables+0x4d/0x80) [ 27.870111] [<c01fd345>] (free_pgtables) from [<c0202bf7>] (exit_mmap+0x8b/0xf0) [ 27.870123] [<c0202bf7>] (exit_mmap) from [<c0117fd7>] (mmput+0x43/0xcc) [ 27.870136] [<c0117fd7>] (mmput) from [<c022df6f>] (flush_old_exec+0x39f/0x574) [ 27.870150] [<c022df6f>] (flush_old_exec) from [<c026b021>] (load_elf_binary+0x1e5/0xe24) [ 27.870161] [<c026b021>] (load_elf_binary) from [<c022e1d3>] (search_binary_handler+0x8f/0x1b0) [ 27.870170] [<c022e1d3>] (search_binary_handler) from [<c0269e59>] (load_script+0x191/0x1a8) [ 27.870179] [<c0269e59>] (load_script) from [<c022e1d3>] (search_binary_handler+0x8f/0x1b0) [ 27.870190] [<c022e1d3>] (search_binary_handler) from [<c022eae5>] (do_execveat_common+0x451/0x580) [ 27.870200] [<c022eae5>] (do_execveat_common) from [<c022edc1>] (SyS_execve+0x25/0x28) [ 27.870212] [<c022edc1>] (SyS_execve) from [<c0106621>] (ret_fast_syscall+0x1/0x62) [ 27.870224] Code: e7d7 2500 4628 bd70 (6d5b) 3300 [ 27.870230] ---[ end trace 22ae546951149d94 ]---

The image you're using is from January this year so already containing our DRAM clockspeed adjustments. Might be worth a try afterwards with memtester (apt install memtester)

Thank you. Voltage/temps look ok but there is a kernel oops reported. Next try: please run in one shell now dmesg -w and in another armbianmonitor -v (package integrity check which indicates problems with corrupted filesystems or SD cards)

No need for an "option" since A20/AXP209 boards like CT are detected automatically. Simply run armbianmonitor -m or even better armbianmonitor -u (since this contains also voltage information for exactly this reason). Thousand of answers here in this forum are wasted just because users are not encouraged to always provide 'armbianmonitor -u' output first. Not even moderators follow this simple rule

I added now results with 2.0/1.5 GHz cpufreq OPP for NanoPC-T4: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md Several things to mention: Memory performance for whatever reasons is way higher with mainline kernel compared to RK's 4.4. This directly affects 7-zip scores (same with a lot of real-world workloads). I get 5540 7-zip MIPS with old 1.8/1.4GHz settings compared to 6250 7-zip MIPS with more recent kernel Your tinymembench numbers for overclocked Firefly are somewhat identical to those from the other boards (I would've assumed they would be significantly higher) RockPro64 tinymembench numbers are lower with mainline kernel compared to NanoPC-T4 (I suspect it's really kernel here that matters since same DRAM initialization BLOBs are used when switching between kernels) RockPro64 7-zip scores with RK's 4.4 kernel are much better compared to NanoPC-T4 running at same clockspeed: 6140 vs. 5530 is massive. And an incentive to compare ayufan's kernel config with the one we use for NanoPC-T4 now Numbers with 1.8/1.4GHz (Firefly using 2.2/1.8), all the time using tinymembench built the same way (GCC 6.3) and Debian Stretch arm64 7zr binary: Board kernel memcpy memset 7-zip NanoPC-T4 4.17 4100 9000 6250 NanoPC-T4 4.4 2840 4890 5530 RockPro64 4.18 3650 8450 6300 RockPro64 4.4 2800 4850 6140 Firefly (OC) 4.18 4150 8280 7900 Firefly (OC) 4.4 2900 4880 7420 OC = overclocked

I was referring to playing YT inside Chromium (not externally via omxplayer): https://lb.raspberrypi.org/forums/viewtopic.php?f=66&amp;t=199543