ArkOS vs dArkOS vs Arch R on the R36S: What We Measured

We ran all three systems on the same R36S WiFi from our own stock, one after another, and measured them rather than repeating what forums say. Some of what we found contradicts the common advice, including our own earlier assumptions.

The short answer

What each one actually is

	ArkOS	dArkOS	Arch R
Base	Ubuntu 19.10	Debian 13	Arch Linux ARM
Kernel	4.4, vendor	4.4, vendor	6.12 mainline
System libraries	2019 era	current	current
Status	retired	maintained	actively developed
Display system	none by default	X11 available	Wayland only

Finding 1: the CPU is faster than you think, and heat is the real limit

Your R36S has ten frequency steps in hardware, topping out at 1.512 GHz. What you actually get depends on the firmware.

	Default max clock	First throttle point
ArkOS	1.512 GHz	85°C
dArkOS	1.296 GHz	85°C
Arch R	1.416 GHz	70°C

dArkOS caps you 14% below what the chip can do, which is easily raised. Arch R disables its top turbo step deliberately, because the project links it to boot loops.

The important finding is that none of this matters much under sustained load. We raised the thermal limit from 85°C to 100°C, then to 105°C. Performance did not improve at all. The chip climbed to whatever ceiling we set, the throttle pinned at its maximum step, and all four cores dropped to 1.008 GHz regardless. The only difference was that it ran twenty degrees hotter for the same result, which is worse for the battery sitting against it.

If you want more sustained performance from an R36S, the answer is a thermal pad inside the shell, not a setting.

Finding 2: the graphics chip is never used by a browser, on any of them

This surprised us most. We checked the graphics chip's own frequency records on Arch R, which count time spent at each speed and every change. Running a browser for an entire session:

• Time at idle speed: 100% of uptime
• Frequency changes: zero

A chip doing work clocks up within milliseconds. Ours never left idle, on any of the three systems.

The reason is the same throughout. The Mali graphics driver supplied for this hardware only comes in a form that suits the display method these systems do not use for browsers. Chrome asks for a display configuration and is refused. On the older kernel we also tested three newer driver versions, and every one rejected the kernel outright with a version mismatch. So on all three systems, browser rendering happens entirely on four modest CPU cores. That is why the console gets hot browsing a web page.

Finding 3: the video decoder exists, but only on Arch R

Your console contains a dedicated video decoding chip. Whether you can reach it is entirely down to the kernel.

	Video device present	Decoder driver
ArkOS	no	none
dArkOS	no	none
Arch R	yes, decoder and encoder	loaded, with H.264, VP9 and JPEG support

This is Arch R's one genuine technical advantage, and it comes from the mainline kernel. The catch is that we could not get any browser to use it, so it remains potential rather than benefit unless you are using software that addresses it directly.

Finding 4: the CPU decodes video far better than expected

We benchmarked the processor decoding a 720p60 video clip in software. It managed five times realtime, around 300 frames per second.

We had assumed this hardware was simply too slow for video streaming. It is not. Decoding was never the bottleneck. What actually limits you is heat, because doing that work on the CPU rather than the dedicated chip generates enough of it to trigger throttling within minutes.

Finding 5: the browser situation is what really separates them

	Newest browser	Cloud gaming
ArkOS	Firefox 78, from 2020	refused, no stream at all
dArkOS	Chrome 152, current	signed in, stream started
Arch R	none in its repository	worked once, then stopped

On ArkOS, cloud gaming failed with an error code on every title. Network monitoring showed why: peak throughput during a launch was about 120 KB/s, against roughly 2 MB/s a real stream needs. Nothing was ever sent. The service rejects a browser that old, and no amount of pretending otherwise helped; we tried making it report a supported version and the failure was unchanged.

On dArkOS the same service accepted Chrome, signed in, and began streaming. That is the practical difference, and it comes down to one thing: modern system libraries, which allow the official ARM64 build of Chrome to install.

On Arch R we got Chrome running by hand and signed in successfully, but there is no browser in the repository, the arrangement is fragile, and after a reboot it stopped starting altogether.

Finding 6: two hardware limits that apply to all three

You have one USB port, and WiFi is using it

Both proper USB host controllers are switched off in this hardware's configuration. Only a single dual-role port is active, and on the WiFi model the internal WiFi module occupies it. Plug a keyboard or mouse into the Type-C socket and WiFi drops off the network. We confirmed this by accident and lost our connection. A powered USB-C hub is the only simple workaround.

The WiFi is right at the edge for streaming

We measured sustained download over a 50 MB transfer at about 15 Mbit/s. That is exactly the minimum a major cloud gaming service asks for, with no headroom, on a single-band radio where interference and jitter hurt more than raw speed.

Our recommendation

Keep it simple: pick by what you actually do.

• Emulation is the whole point for you. Arch R. Modern kernel, active development, real package manager, and the video decoder available for software that can use it.
• You want a browser on the device. dArkOS. It is the only one where a current browser installs cleanly and keeps working, and the setup is stable.
• You want cloud gaming specifically. dArkOS, with realistic expectations. It works, but the screen is 640x480 against services whose smallest stream is larger, the WiFi sits at the minimum, and the console throttles within minutes because the CPU is doing the decoding.
• You want the best gaming performance this handheld can reach. Stream from your own PC on your own network instead. That path uses the hardware properly, is not limited by your broadband, and needs no browser at all.

Whichever you choose, put it on a spare card. Swapping back takes thirty seconds, and it costs nothing to change your mind.

We test this on the exact consoles we sell. Questions about any of it, message us on WhatsApp from the product page.