GMKtec K10

Benchmarks against DL 380 G9ඞ

Green:

• Processor: Intel Core i9-13900HK @ 5.20GHz (14 Cores / 20 Threads)
• Motherboard: GMKtec (NucBox K10 0.12 BIOS)
• Chipset: Intel Alder Lake PCH
• Memory: 2 x 32 GB DDR5-5200MT/s
• Disk: 1000GB CT1000E100SSD8
• Graphics: Intel Raptor Lake-P [Iris Xe] (1500MHz)
• Audio: Conexant SN6140
• Network: Realtek RTL8125 2.5GbE + Intel Raptor Lake PCH CNVi WiFi
• OS: Rocky Linux 10.0
• Kernel: 6.12.0-55.22.1.el10_0.x86_64 (x86_64)
• Compiler: GCC 14.2.1 20250110
• File-System: xfs
• Physical dimensions: 9.8 x 10.3 x 4.2 cm
• Weight: 2.2kg
• Power draw (idle): 18W
• Power draw (max): 120W

Sol:

• Processor: 2 x Intel Xeon E5-2637 v3 @ 3.70GHz (8 Cores / 16 Threads)
• Motherboard: HP ProLiant DL380 Gen9 (P89 BIOS)
• Chipset: Intel Xeon E7 v3/Xeon
• Memory: 16 x 16 GB DDR4-2133MT/s 752369-081
• Disk: 2400GB LOGICAL VOLUME (8x600GB 10K SAS RAID10 Storage Controller HP Smart Array P440ar)
• Graphics: Matrox MGA G200EH
• Network: 4 x Broadcom NetXtreme BCM5719 PCIe
• OS: Debian 12
• Kernel: 6.8.12-9-pve (x86_64)
• Compiler: GCC 12.2.0
• File-System: ext4
• Physical dimensions: 8.73 x 44.55 x 67.94 cm
• Weight: 23.6 kg
• Power draw (idle): 112W
• Power draw (max): 500W

CPU Benchmarksඞ

Sol has: 2 x Intel Xeon E5-2637 v3 @ 3.70GHz (8 Cores / 16 Threads)

Green has: Intel Core i9-13900HK @ 5.20GHz (14 Cores / 20 Threads)

Results on openbenchmarking.org:

• https://openbenchmarking.org/result/2509137-NE-SOLCPU35817
• https://openbenchmarking.org/result/2509117-NE-GREENCPU761

CPU Benchmarks with only P-coresඞ

Since i9-13900HK features two kinds of cores, performance aka P-cores and efficiency aka E-cores (also known as Atom cores), it provided an interesting opportunity to test performance with E-cores off.

Check for E-cores: cat /sys/devices/cpu_atom/cpus

Run task on specific cores (0-11 are P-cores in this case): taskset -c 0-11 <COMMAND>

Results on openbenchmarking.org: https://openbenchmarking.org/result/2509142-NE-CPUGREENN25

Multi-threaded tasks benefit significantly from E-cores. Decompression sees a bigger relative improvement, likely due to better multi-thread scaling. Full core usage speeds up compilation by about a third.

Single-threaded or lightly threaded tasks benefit less but still gain some improvement when E-cores assist background threads.

Redis throughput improves dramatically with E-cores enabled, especially at lower concurrency where single-thread performance matters less, and total parallelism dominates.

For mixed workloads (databases, Redis, compression, video encoding), enabling all cores is needed for maximum performance. Disabling E-cores mainly limits total throughput for parallel tasks.

CPU Benchmarks with only one CPU on dual socketඞ

Since Sol has two CPU sockets and dual CPUs, it was interesting to run benchmarks only on one of them to see a difference in terms of more equal comparison in terms of core/thread counts between the systems and, perhaps, to see how much NUMA affects the results.

Run task only on first CPU: numactl --cpubind=0 --membind=0 <COMMAND>

Results on openbenchmarking.org: https://openbenchmarking.org/result/2509146-NE-CPUSOLSIN78

Compute-heavy workloads (7-Zip, OpenSSL, kernel build) scale almost perfectly (~2x) with both sockets.

x265 scaling is poor - single-socket actually edges out dual in 4K and is nearly identical in 1080p.

CPU Bench Summaryඞ

Green has way better IPC with modern architecture, and in some cases can beat parallel loads (7-Zip compression) even if Sol has more threads.

Cryptography improvements likely due to AVX2/AVX512 and AES-NI optimizations on Alder Lake vs Haswell-era Xeons. Surprisingly ChaCha20 performance is equal or even slightly better on Sol, indicating that Green's crypto accelerators favor AES but not ChaCha20. Also RSA4096 and other public-key operations scale less dramatically (~1.5-1.6x), reflecting their compute-bound nature with less dependency on memory bandwidth. ChaCha20 being faster on older Xeon is a rare scenario where lack of AES acceleration helps.

Green consistently outperforms Sol on Redis benchmarks. However at higher concurrent connections, performance delta shrinks slightly, indicating that memory and I/O subsystem become the bottleneck at scale.

MariaDB results in a massive difference in performance not just due to CPU but also NVMe vs RAID SAS latency. CPU cannot shine fully if disk latency dominates.

Disk Benchmarksඞ

Sol has: 2400GB LOGICAL VOLUME (8x600GB 10K SAS RAID10 Storage Controller HP Smart Array P440ar) on ext4

Green has: NVMe 1000GB CT1000E100SSD8 on xfs

Results on openbenchmarking.org:

• https://openbenchmarking.org/result/2509115-NE-DISKGREEN01
• https://openbenchmarking.org/result/2509145-NE-DISKSOL7014

Disk Benchmark Summaryඞ

SMP performance due to DDR5's higher frequency and wider bus per channel.

STREAM benchmarks favor Sol which is likely due to Sol's 4-channel DDR4 memory configuration (16 DIMMs across 2 CPUs), providing higher aggregate bandwidth despite slower individual DIMMs. STREAM favoring Sol shows multi-channel DDR4 can beat DDR5 for large sequential streams, but only for continuous bulk operations.

Green shows enormous advantage in cache writes, reflecting modern CPU caches with higher associativity and faster L2/L3.

Green's memcpy/memset performance shows low-latency benefits for small-block memory operations.

Threaded memory operations show Green's superior per-thread latency and IPC, particularly in multi-threaded small-memory scenarios.

Green benefits from modern DDR5 and low-latency caches for small-block memory and per-thread operations, whereas Sol's memory excels in sustained high-bandwidth workloads due to many-channel DDR4 configuration.

RAM Benchmarksඞ

Sol has: 16 x 16 GB DDR4-2133MT/s 752369-081

Green has: 2 x 32 GB DDR5-5200MT/s

Results on openbenchmarking.org:

• https://openbenchmarking.org/result/2509141-NE-RAMSOL48015
• https://openbenchmarking.org/result/2509145-NE-RAMGREEN277

RAM Benchmark Summaryඞ

SQLite single-threaded performance shows 24x advantage for Green; even with multiple threads, Green dominates. NVMe latency vs SAS explains this.

FIO sequential/random throughput is 2-2.5x higher on Green. NVMe scales better due to deep queue depth and modern controller efficiency.

IOR shows Green achieving 6-13x higher MB/s, with the delta shrinking for very large I/O blocks (32-1024MB). This suggests that RAID10 overhead in Sol becomes less significant for very large sequential transfers, but NVMe still dominates.

FS-Mark and Dbench show Green is ~16-19x faster. This is the combined effect of NVMe low latency, XFS efficiency, and fewer mechanical seek delays than 10K SAS disks.

NVMe SSDs provide massive latency and throughput advantages for small and large workloads alike. RAID10 SAS arrays are good for sustained large-block transfers, but fall behind in low-latency, metadata-heavy scenarios.

Overall notesඞ

Green's smaller core count is offset by high IPC, modern caches, and DDR5 bandwidth. Many benchmarks (MariaDB, Redis, crypto) show that per-core performance is more important than total threads, especially for latency-sensitive workloads.

MariaDB and SQLite show extreme differences, not just due to CPU but also NVMe vs RAID SAS latency.

High-speed RAM benefits NVMe latency hiding. Small-block I/O (SQLite, Dbench) benefits from Green's faster memory and cache hierarchy. Sol's large-channel memory helps for sustained sequential FIO reads, but cannot compensate for mechanical seek times in small-block workloads.

Enterprise Xeons still shine in extreme multi-threaded sequential memory or I/O scenarios, but their architecture is tuned for consistency and parallel throughput, not latency-sensitive operations.