Minisforum MS-R1
## Basic information
- Board URL (official): https://s.minisforum.com/4hRFZbj
- Board purchased from: Provided by Minisforum
- Board purchase date: November 10, 2025
- Board specs (as tested): 64GB RAM, 1TB HDD
- Board price (as tested): $695.90 (MSRP $869)
## Linux/system information
```
# output of `screenfetch`
_,met$$$$$gg. OS: Debian 12 bookworm
,g$$$$$$$$$$$$$$$P. Kernel: aarch64 Linux 6.6.10-cix-build-generic
,g$$P"" """Y$$.". Shell: bash 5.2.15
,$$P' `$$$. DE: GNOME 43.6
',$$P ,ggs. `$$b: WM Theme:
`d$$' ,$P"' . $$$ Icon Theme: Adwaita
$$P d$' , $$P Disk: 12G / 925G (2%)
$$: $$. - ,d$$' RAM: 2056MiB / 63833MiB
$$\; Y$b._ _,d$P' Uptime: 2m
Y$$. `.`"Y$$$$P"' Packages: 1433
`$$b "-.__ GTK Theme: Adwaita [GTK2/3]
`Y$$ Font: Cantarell 11
`Y$$. Resolution: 3840x2160
`$$b. WM: Mutter
`Y$$b. CPU: CIX P1 CP8180 @ 12x 2.6GHz
`"Y$b._ mini@ms-r1
`""""
# output of `uname -a`
Linux ms-r1 6.6.10-cix-build-generic #2 SMP PREEMPT Fri Oct 10 10:21:15 UTC 2025 aarch64 GNU/Linux
```
## Benchmark results
### CPU
- Geekbench 6: (1336 single / 6773 multi - https://browser.geekbench.com/v6/cpu/14893385)
- 143.03 Gflops at 39W for **3.67 Gflops/W** ([geerlingguy/top500-benchmark](https://github.com/geerlingguy/top500-benchmark) [HPL result](https://github.com/geerlingguy/top500-benchmark/issues/82))
### Power
- Idle power draw (at wall): 17 W (18.1 W with 10 Gbps Network)
- Maximum simulated power draw (`stress-ng --matrix 0`): 30.3 W
- During Geekbench multicore benchmark: 34.7 W
- During `top500` HPL benchmark: 40 W
### Disk
#### KINGSTON OM8TAP41024K1-A00
| Benchmark | Result |
| -------------------------- | ------ |
| iozone 4K random read | 70.36 MB/s |
| iozone 4K random write | 253.85 MB/s |
| iozone 1M random read | 2783.00 MB/s |
| iozone 1M random write | 4678.96 MB/s |
| iozone 1M sequential read | 3218.89 MB/s |
| iozone 1M sequential write | 4678.47 MB/s |
### Network
`iperf3` results:
#### Built-in 10 Gbps NIC (Realtek RTL8127)
- `iperf3 -c $SERVER_IP`: 9.40 Gbps
- `iperf3 -c $SERVER_IP --reverse`: 3.66 Gbps
- `iperf3 -c $SERVER_IP --bidir`: 7.87 Gbps up, 1.97 Gbps down
#### Built-in WiFi 6E (Mediatek MT7922 802.11ax)
- `iperf3 -c $SERVER_IP`: 925 Mbps
- `iperf3 -c $SERVER_IP --reverse`: 659 Mbps
- `iperf3 -c $SERVER_IP --bidir`: 497 Mbps up, 385 Mbps down
(Be sure to test all interfaces, noting any that are non-functional.)
## GPU
### glmark2
`glmark2-es2-wayland` results:
```
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: ARM
GL_RENDERER: Mali-G720-Immortalis
GL_VERSION: OpenGL ES 3.2 v1.r53p0-00eac0.c707efa0cfa034b363bc93f9b6749cb5
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 8009 FrameTime: 0.125 ms
[build] use-vbo=true: FPS: 8127 FrameTime: 0.123 ms
[texture] texture-filter=nearest: FPS: 8954 FrameTime: 0.112 ms
[texture] texture-filter=linear: FPS: 9057 FrameTime: 0.110 ms
[texture] texture-filter=mipmap: FPS: 7269 FrameTime: 0.138 ms
[shading] shading=gouraud: FPS: 7464 FrameTime: 0.134 ms
[shading] shading=blinn-phong-inf: FPS: 7733 FrameTime: 0.129 ms
[shading] shading=phong: FPS: 7362 FrameTime: 0.136 ms
[shading] shading=cel: FPS: 7340 FrameTime: 0.136 ms
[bump] bump-render=high-poly: FPS: 4475 FrameTime: 0.223 ms
[bump] bump-render=normals: FPS: 8431 FrameTime: 0.119 ms
[bump] bump-render=height: FPS: 8068 FrameTime: 0.124 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 7375 FrameTime: 0.136 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 6361 FrameTime: 0.157 ms
[pulsar] light=false:quads=5:texture=false: FPS: 8637 FrameTime: 0.116 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 3448 FrameTime: 0.290 ms
[desktop] effect=shadow:windows=4: FPS: 5792 FrameTime: 0.173 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 1033 FrameTime: 0.968 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 967 FrameTime: 1.035 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 1504 FrameTime: 0.665 ms
[ideas] speed=duration: FPS: 3383 FrameTime: 0.296 ms
[jellyfish] <default>: FPS: 7069 FrameTime: 0.141 ms
[terrain] <default>: FPS: 540 FrameTime: 1.852 ms
[shadow] <default>: FPS: 6465 FrameTime: 0.155 ms
[refract] <default>: FPS: 1637 FrameTime: 0.611 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 8265 FrameTime: 0.121 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 7309 FrameTime: 0.137 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 8383 FrameTime: 0.119 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 7999 FrameTime: 0.125 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 7227 FrameTime: 0.138 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 7884 FrameTime: 0.127 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 7811 FrameTime: 0.128 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 7313 FrameTime: 0.137 ms
=======================================================
glmark2 Score: 6322
=======================================================
```
### vkmark
`vkmark` results (had to be [compiled](https://github.com/geerlingguy/sbc-reviews/issues/76) as it wasn't available on the default Debian 12 package repository):
```
mini@ms-r1:~/Downloads/vkmark$ DISPLAY=:0 build/src/vkmark --winsys-dir=build/src --data-dir=data
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Error: Failed to find a connected drm connector
```
I also tried using `vulkaninfo`, but got:
```
mini@ms-r1:~/Downloads/vkmark$ vulkaninfo
Segmentation fault
```
Apparently [some users got Vulkan going on the Radxa Orion O6](https://forum.radxa.com/t/what-gpu-can-i-use-with-the-orion-to-run-llms/26620/3?u=geerlingguy), but reported incredibly slow inference with llama.cpp, suggesting the memory connection between the iGPU and the LPDDR5 RAM is not so great.
### GravityMark
GravityMark result: [3,037](https://gravitymark.tellusim.com/report/?id=b47bb5b8bad5c54937dc475f1cdd7cf2607a37da)
<img width="1600" height="900" alt="Image" src="https://github.com/user-attachments/assets/edc1cef9-d2fb-456c-bcd4-6d9fef535358" />
### AI / LLM Inference
Basic `ollama` LLM model inference results:
| System | CPU/GPU | Model | Eval Rate | Power (Peak) |
| :--- | :--- | :--- | :--- | :--- |
| Minisforum MS-R1 | CPU | llama3.2:3b | 12.12 Tokens/s | 35 W |
| Minisforum MS-R1 | CPU | llama3.1:8b | 5.78 Tokens/s | 35 W |
| Minisforum MS-R1 | CPU | llama2:13b | 3.91 Tokens/s | 37.2 W |
| Minisforum MS-R1 | CPU | llama3.1:70b | 0.77 Tokens/s | 38.2 W |
| Minisforum MS-R1 (Nvidia RTX A2000) | GPU | llama3.2:3b | 71.36 Tokens/s | 94.3 W |
| Minisforum MS-R1 (Nvidia RTX A2000) | GPU | llama3.1:8b | 34.52 Tokens/s | 97.3 W |
More results: https://github.com/geerlingguy/ai-benchmarks/issues/32
Ollama was run on the CPU for these tests, as I could not yet get Vulkan support working, and could not get either Llama.cpp or Ollama to use Vulkan on the iGPU.
## Memory
`tinymembench` results:
<details>
<summary>Click to expand memory benchmark result</summary>
```
tinymembench v0.4.10 (simple benchmark for memory throughput and latency)
==========================================================================
== Memory bandwidth tests ==
== ==
== Note 1: 1MB = 1000000 bytes ==
== Note 2: Results for 'copy' tests show how many bytes can be ==
== copied per second (adding together read and writen ==
== bytes would have provided twice higher numbers) ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
== to first fetch data into it, and only then write it to the ==
== destination (source -> L1 cache, L1 cache -> destination) ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in ==
== brackets ==
==========================================================================
C copy backwards : 15141.6 MB/s (3.3%)
C copy backwards (32 byte blocks) : 15462.1 MB/s (0.7%)
C copy backwards (64 byte blocks) : 15509.4 MB/s (0.4%)
C copy : 15559.3 MB/s (2.7%)
C copy prefetched (32 bytes step) : 14131.9 MB/s (1.2%)
C copy prefetched (64 bytes step) : 14256.6 MB/s (1.9%)
C 2-pass copy : 14304.2 MB/s (0.4%)
C 2-pass copy prefetched (32 bytes step) : 13702.7 MB/s
C 2-pass copy prefetched (64 bytes step) : 14443.0 MB/s
C fill : 35112.0 MB/s (2.1%)
C fill (shuffle within 16 byte blocks) : 35279.8 MB/s (0.3%)
C fill (shuffle within 32 byte blocks) : 35368.0 MB/s
C fill (shuffle within 64 byte blocks) : 35707.0 MB/s (0.6%)
NEON 64x2 COPY : 16145.3 MB/s (0.3%)
NEON 64x2x4 COPY : 16148.5 MB/s (0.2%)
NEON 64x1x4_x2 COPY : 15632.7 MB/s (0.2%)
NEON 64x2 COPY prefetch x2 : 15784.8 MB/s
NEON 64x2x4 COPY prefetch x1 : 16216.8 MB/s (0.4%)
NEON 64x2 COPY prefetch x1 : 16329.7 MB/s
NEON 64x2x4 COPY prefetch x1 : 16288.4 MB/s (0.3%)
---
standard memcpy : 16556.4 MB/s (1.7%)
standard memset : 41295.1 MB/s (1.9%)
---
NEON LDP/STP copy : 16698.8 MB/s (2.0%)
NEON LDP/STP copy pldl2strm (32 bytes step) : 15435.9 MB/s (2.1%)
NEON LDP/STP copy pldl2strm (64 bytes step) : 15425.3 MB/s (1.1%)
NEON LDP/STP copy pldl1keep (32 bytes step) : 15966.3 MB/s (1.0%)
NEON LDP/STP copy pldl1keep (64 bytes step) : 16154.9 MB/s (0.4%)
NEON LD1/ST1 copy : 15877.5 MB/s
NEON STP fill : 36616.6 MB/s (2.6%)
NEON STNP fill : 34990.0 MB/s (2.8%)
ARM LDP/STP copy : 16254.1 MB/s (1.7%)
ARM STP fill : 39698.1 MB/s (3.4%)
ARM STNP fill : 35023.4 MB/s (2.8%)
==========================================================================
== Framebuffer read tests. ==
== ==
== Many ARM devices use a part of the system memory as the framebuffer, ==
== typically mapped as uncached but with write-combining enabled. ==
== Writes to such framebuffers are quite fast, but reads are much ==
== slower and very sensitive to the alignment and the selection of ==
== CPU instructions which are used for accessing memory. ==
== ==
== Many x86 systems allocate the framebuffer in the GPU memory, ==
== accessible for the CPU via a relatively slow PCI-E bus. Moreover, ==
== PCI-E is asymmetric and handles reads a lot worse than writes. ==
== ==
== If uncached framebuffer reads are reasonably fast (at least 100 MB/s ==
== or preferably >300 MB/s), then using the shadow framebuffer layer ==
== is not necessary in Xorg DDX drivers, resulting in a nice overall ==
== performance improvement. For example, the xf86-video-fbturbo DDX ==
== uses this trick. ==
==========================================================================
NEON LDP/STP copy (from framebuffer) : 2156.6 MB/s
NEON LDP/STP 2-pass copy (from framebuffer) : 1524.4 MB/s
NEON LD1/ST1 copy (from framebuffer) : 2156.4 MB/s
NEON LD1/ST1 2-pass copy (from framebuffer) : 1529.3 MB/s
ARM LDP/STP copy (from framebuffer) : 1934.8 MB/s
ARM LDP/STP 2-pass copy (from framebuffer) : 1211.3 MB/s
==========================================================================
== Memory latency test ==
== ==
== Average time is measured for random memory accesses in the buffers ==
== of different sizes. The larger is the buffer, the more significant ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM ==
== accesses. For extremely large buffer sizes we are expecting to see ==
== page table walk with several requests to SDRAM for almost every ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest). ==
== ==
== Note 1: All the numbers are representing extra time, which needs to ==
== be added to L1 cache latency. The cycle timings for L1 cache ==
== latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
== two independent memory accesses at a time. In the case if ==
== the memory subsystem can't handle multiple outstanding ==
== requests, dual random read has the same timings as two ==
== single reads performed one after another. ==
==========================================================================
block size : single random read / dual random read, [MADV_NOHUGEPAGE]
1024 : 0.0 ns / 0.0 ns
2048 : 0.0 ns / 0.0 ns
4096 : 0.0 ns / 0.0 ns
8192 : 0.0 ns / 0.0 ns
16384 : 0.0 ns / 0.0 ns
32768 : 0.0 ns / 0.0 ns
65536 : 0.0 ns / 0.0 ns
131072 : 1.0 ns / 1.5 ns
262144 : 1.5 ns / 2.1 ns
524288 : 2.1 ns / 2.4 ns
1048576 : 18.4 ns / 26.7 ns
2097152 : 26.6 ns / 33.6 ns
4194304 : 31.0 ns / 35.9 ns
8388608 : 33.7 ns / 36.8 ns
16777216 : 41.2 ns / 48.0 ns
33554432 : 109.9 ns / 153.1 ns
67108864 : 173.4 ns / 217.5 ns
block size : single random read / dual random read, [MADV_HUGEPAGE]
1024 : 0.0 ns / 0.0 ns
2048 : 0.0 ns / 0.0 ns
4096 : 0.0 ns / 0.0 ns
8192 : 0.0 ns / 0.0 ns
16384 : 0.0 ns / 0.0 ns
32768 : 0.0 ns / 0.0 ns
65536 : 0.0 ns / 0.0 ns
131072 : 1.0 ns / 1.5 ns
262144 : 1.5 ns / 2.1 ns
524288 : 1.8 ns / 2.4 ns
1048576 : 17.5 ns / 26.1 ns
2097152 : 25.3 ns / 32.3 ns
4194304 : 29.1 ns / 34.4 ns
8388608 : 33.5 ns / 35.0 ns
16777216 : 39.1 ns / 46.1 ns
33554432 : 107.6 ns / 151.1 ns
67108864 : 159.1 ns / 202.4 ns
```
</details>
### Core to Core Memory Latency
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/ceeeb4c4-5081-4f9b-9818-993ca22ba1da" />
Note: According to Minisforum's documentation, "cores "0-1,10-11" are big cores; "6-9" are middle cores; "2-5" are small cores."
## `sbc-bench` results
Run sbc-bench and paste a link to the results here: https://github.com/ThomasKaiser/sbc-bench/issues/126
## Phoronix Test Suite
Results from [pi-general-benchmark.sh](https://gist.github.com/geerlingguy/570e13f4f81a40a5395688667b1f79af):
- pts/encode-mp3: 8.762 sec
- pts/x264 1080p: 53.43 fps
- pts/x264 4K: 12.93 fps
- pts/phpbench: 649067
- pts/build-linux-kernel (defconfig): 896.561 sec
44 条评论