geerlingguy
commented
2 months ago A few notes unboxing and assembling this SBC with it's Lite Carrier ($40) and their official Aluminum Active Cooler ($12):
- Custom 260-pin SO-DIMM edge pinout, BIOS, board layout examples, mechanical drawings, etc. are provided in the LattePanda-Mu GitHub project. It is provided under the MIT license, so examples can easily be modified for your own purposes.
- Note: This is great, especially having the official carrier boards' design files included, because it immediately gives devs who can use KiCAD enough data to go on to customize an existing reference design, just like Raspberry Pi did with their CM4 carrier board.
- The full kit looks like it includes a nice printed manual (as documented at 11:40 in Technically Unsure's video.
- The lite board includes an open-ended PCIe Gen 3 x4 slot, which apparently is only powered when using DC barrel jack power (12V DC), but not using 15V USB-C PD input.
- The Lite board includes 2x USB 3.0, 2x USB 2.0, Ethernet (1 Gbps), HDMI, and 12V barrel plug or 15V USB-C PD power input.
- The active cooler fits over the rather large (compared to typical SBCs) N100 chip using three spring-loaded screws. I would not crank the screws down 100% tight, as there is ever-so-slight board flex if you attempt that.
- DFRobot intends to make a higher-RAM variant at some point in the future (16GB was mentioned).
- The official web page for the product lists a few potential future expansion boards: NAS carrier with 10 GbE (4x?) and 8 NVMe M.2 2280 slots, Router Carrier with 4x Ethernet jacks with PoE power output (maybe?), Graphics Carrier with MXM, SXM, OAM, or general PCIe cards, and a Cluster Carrier for multiple Mu boards. The illustrations show extremely basic designs lacking networking, power circuitry, etc. meaning those are likely quick illustrations to show potential future products based on what's stuck for things like the Pi Compute Module 4.
- Spitballing... this module might be the easiest way for someone to build their own custom Intel-based PC, and with decent baseline specs. It'd be awesome if DFRobot can commit to building up the hardware ecosystem around the Mu, and maybe commit to long-term production (I didn't see anything about that on their website).
As MKBHD says (paraphrased), "don't buy a product based on future promises" — but is the Mu good enough to stand on its own merits, and could an ecosystem develop around this form factor like it has around the Compute Modules?
ThomasKaiser
UnKnoWn-Consortium
kesavvvvv
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0): 22.1 Wtop500HPL benchmark: 25 WDisk
Built-in 64GB eMMC storage
Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading.
Also consider running PiBenchmarks.com script.
Network
iperf3results:iperf3 -c $SERVER_IP: 942 Mbpsiperf3 --reverse -c $SERVER_IP: 838 Mbpsiperf3 --bidir -c $SERVER_IP: 937 Mbps up, 544 Mbps down(Be sure to test all interfaces, noting any that are non-functional.)
GPU
glmark2-es2results:Note: This benchmark requires an active display on the device. Not all devices may be able to run
glmark2-es2, so in that case, make a note and move on!TODO: See this issue for discussion about a full suite of standardized GPU benchmarks.
Memory
tinymembenchresults:Click to expand memory benchmark result
``` 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 : 8198.4 MB/s C copy backwards (32 byte blocks) : 8208.1 MB/s C copy backwards (64 byte blocks) : 8261.9 MB/s C copy : 7887.9 MB/s C copy prefetched (32 bytes step) : 4901.8 MB/s (0.2%) C copy prefetched (64 bytes step) : 5062.2 MB/s C 2-pass copy : 6949.3 MB/s C 2-pass copy prefetched (32 bytes step) : 3770.8 MB/s C 2-pass copy prefetched (64 bytes step) : 3773.3 MB/s C fill : 10764.4 MB/s (0.1%) C fill (shuffle within 16 byte blocks) : 10727.3 MB/s C fill (shuffle within 32 byte blocks) : 10721.1 MB/s C fill (shuffle within 64 byte blocks) : 10724.3 MB/s --- standard memcpy : 10790.2 MB/s standard memset : 11019.0 MB/s --- MOVSB copy : 8201.1 MB/s MOVSD copy : 8202.8 MB/s SSE2 copy : 8201.2 MB/s SSE2 nontemporal copy : 10945.0 MB/s SSE2 copy prefetched (32 bytes step) : 6560.1 MB/s SSE2 copy prefetched (64 bytes step) : 6840.2 MB/s SSE2 nontemporal copy prefetched (32 bytes step) : 7616.0 MB/s (0.1%) SSE2 nontemporal copy prefetched (64 bytes step) : 8108.0 MB/s (0.2%) SSE2 2-pass copy : 6572.6 MB/s SSE2 2-pass copy prefetched (32 bytes step) : 4806.6 MB/s SSE2 2-pass copy prefetched (64 bytes step) : 4963.1 MB/s SSE2 2-pass nontemporal copy : 3277.9 MB/s SSE2 fill : 11019.0 MB/s SSE2 nontemporal fill : 19722.2 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 : 2.5 ns / 3.7 ns 131072 : 3.8 ns / 4.6 ns 262144 : 5.1 ns / 6.0 ns 524288 : 6.4 ns / 7.2 ns 1048576 : 7.0 ns / 7.5 ns 2097152 : 7.6 ns / 7.9 ns 4194304 : 13.7 ns / 16.8 ns 8388608 : 28.6 ns / 40.5 ns 16777216 : 77.1 ns / 110.5 ns 33554432 : 108.5 ns / 136.6 ns 67108864 : 120.0 ns / 134.1 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 : 2.5 ns / 3.7 ns 131072 : 3.8 ns / 4.6 ns 262144 : 4.4 ns / 4.9 ns 524288 : 4.7 ns / 5.0 ns 1048576 : 4.9 ns / 5.0 ns 2097152 : 5.1 ns / 5.1 ns 4194304 : 11.2 ns / 14.3 ns 8388608 : 25.2 ns / 37.1 ns 16777216 : 71.5 ns / 103.7 ns 33554432 : 99.3 ns / 124.5 ns 67108864 : 112.1 ns / 131.2 ns ```sbc-benchresultsResults: https://sprunge.us/uHzXI7
Phoronix Test Suite
Results from pi-general-benchmark.sh: