geerlingguy
commented
2 weeks ago Getting full 25 Gbps Ethernet on the 2nd interface:
ubuntu@ubuntu:~$ ethtool eno2np1
Settings for eno2np1:
Supported ports: [ FIBRE ]
Supported link modes: 25000baseCR/Full
1000baseX/Full
10000baseCR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: RS BASER
Advertised link modes: 25000baseCR/Full
1000baseX/Full
10000baseCR/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 25000Mb/s
Lanes: 1
Duplex: Full
Auto-negotiation: on
Port: Direct Attach Copper
PHYAD: 1
Transceiver: internal
netlink error: Operation not permitted
Current message level: 0x00002081 (8321)
drv tx_err hw
Link detected: yesIf I try running Geekbench 6 I get a core dump, lol:
ubuntu@ubuntu:~/Geekbench-6.3.0-LinuxARMPreview$ ./geekbench6
<jemalloc>: Unsupported system page size
<jemalloc>: Unsupported system page size
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)I opened up a support issue for that: Can't run Geekbench 6 Arm Preview on AmpereOne 192-core system
ThomasKaiser
hrw
bexcran
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0): 500 Wtop500HPL benchmark: 692 WDisk
Samsung NVMe SSD - 983 DCT M.2 960GB
Samsung NVMe SSD - MZQL21T9HCJR-00A07
Specs: https://semiconductor.samsung.com/ssd/datacenter-ssd/pm9a3/mzql21t9hcjr-00a07/
Single disk
RAID 0 (mdadm)
Network
iperf3results:iperf3 -c $SERVER_IP: 21.4 Gbpsiperf3 -c $SERVER_IP --reverse: 18.8 Gbpsiperf3 -c $SERVER_IP --bidir: 8.08 Gbps up, 22.2 Gbps downTested on one of the two built-in Broadcom
BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controllerinterfaces, to my HL15 Arm NAS (see: https://github.com/geerlingguy/arm-nas/issues/16), routed through a Mikrotik 25G Cloud Router.GPU
Did not test - this server doesn't have a GPU, just the ASPEED integrated BMC VGA graphics, which are not suitable for much GPU-accelerated gaming or LLMs, lol. Just render it on CPU!
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 : 14199.7 MB/s (0.3%) C copy backwards (32 byte blocks) : 13871.7 MB/s C copy backwards (64 byte blocks) : 13879.6 MB/s (0.2%) C copy : 13890.6 MB/s (0.2%) C copy prefetched (32 bytes step) : 14581.4 MB/s C copy prefetched (64 bytes step) : 14613.8 MB/s C 2-pass copy : 10819.4 MB/s C 2-pass copy prefetched (32 bytes step) : 11313.6 MB/s C 2-pass copy prefetched (64 bytes step) : 11417.4 MB/s C fill : 31260.2 MB/s C fill (shuffle within 16 byte blocks) : 31257.1 MB/s C fill (shuffle within 32 byte blocks) : 31263.1 MB/s C fill (shuffle within 64 byte blocks) : 31260.9 MB/s NEON 64x2 COPY : 14464.3 MB/s (0.9%) NEON 64x2x4 COPY : 13694.9 MB/s NEON 64x1x4_x2 COPY : 12444.6 MB/s NEON 64x2 COPY prefetch x2 : 14886.9 MB/s NEON 64x2x4 COPY prefetch x1 : 14954.4 MB/s NEON 64x2 COPY prefetch x1 : 14892.3 MB/s NEON 64x2x4 COPY prefetch x1 : 14955.5 MB/s --- standard memcpy : 14141.9 MB/s standard memset : 31268.0 MB/s --- NEON LDP/STP copy : 13775.1 MB/s (0.7%) NEON LDP/STP copy pldl2strm (32 bytes step) : 14267.3 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 14340.9 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 14670.0 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 14644.7 MB/s NEON LD1/ST1 copy : 13756.1 MB/s NEON STP fill : 31262.2 MB/s NEON STNP fill : 31265.7 MB/s ARM LDP/STP copy : 14454.0 MB/s (0.6%) ARM STP fill : 31265.6 MB/s ARM STNP fill : 31266.0 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.1 ns / 1.6 ns 262144 : 1.7 ns / 2.0 ns 524288 : 1.9 ns / 2.2 ns 1048576 : 2.1 ns / 2.2 ns 2097152 : 3.0 ns / 3.3 ns 4194304 : 22.6 ns / 33.9 ns 8388608 : 33.7 ns / 44.3 ns 16777216 : 39.3 ns / 48.0 ns 33554432 : 42.1 ns / 49.4 ns 67108864 : 49.0 ns / 60.2 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.1 ns / 1.6 ns 262144 : 1.7 ns / 2.0 ns 524288 : 1.9 ns / 2.2 ns 1048576 : 2.1 ns / 2.2 ns 2097152 : 3.0 ns / 3.3 ns 4194304 : 22.6 ns / 33.9 ns 8388608 : 33.7 ns / 44.3 ns 16777216 : 39.3 ns / 47.9 ns 33554432 : 42.1 ns / 49.4 ns 67108864 : 49.9 ns / 61.9 ns ```sbc-benchresultsRun sbc-bench and paste a link to the results here: https://0x0.st/X0gc.bin
See: https://github.com/ThomasKaiser/sbc-bench/issues/105
Phoronix Test Suite
Results from pi-general-benchmark.sh:
Additional benchmarks
QEMU Coremark
The Ampere team have suggested running this, as it will emulate running tons of virtual instances with coremark inside, a good proxy of the type of performance you can get with VMs/containers on this system: https://github.com/AmpereComputing/qemu-coremark
llama.cpp (Ampere-optimized)
See: https://github.com/AmpereComputingAI/llama.cpp (I also have an email from Ampere with some testing notes).
Ollama (generic LLMs)
See: https://github.com/geerlingguy/ollama-benchmark?tab=readme-ov-file#findings
yolo-v5
See: https://github.com/AmpereComputingAI/yolov5-demo (maybe test it on a 4K60 video, see how it fares).