Interpreting Results

Interpreting Results

In short

YABS prints numbers and deliberately never tells you whether they are good or bad. This page is the missing judgement layer: what each number means, what range to expect from each kind of hardware, how to recognise caching, throttling and overloaded hosts, and which rows actually matter for the way you plan to use the server. Read it alongside Understanding the Output (what each line is) and Benchmarks Are Snapshots (why one run proves little).

Three rules before any number:

1. Compare like with like. Same YABS version era, same Geekbench version, similar time of day, and ideally the same CPU model in a results database.
2. Judge against what you were sold. A 1 Gbps port that does 940 Mbit/s is perfect; the same number on a 10 Gbps port is a problem. "NVMe" that performs like a hard disk is a problem; a hard-disk plan that performs like a hard disk is not.
3. One run is one sample. Anything surprising should be re-run at a different hour before you draw conclusions.

All ranges on this page are orientation figures gathered from published device specifications, Geekbench's own CPU charts, and several years of community-posted YABS results. They are not thresholds, and hardware moves on. Where a figure comes from a specific source it is attributed.

Want this applied to your own result automatically? Paste it into the assessment tool at https://stats.yabs.sh/assess. It encodes the checks on this page (storage-class fingerprint, cache and QoS signatures, nearest-server port check, Geekbench landmarks and scaling, context caveats) and links each finding back to the relevant section. It runs entirely in your browser; nothing is uploaded.

Table of contents

• Start with the system information block
• Disk: reading the fio table
• Network: reading the iperf3 table
• CPU: reading the Geekbench scores
• Spotting an overloaded or oversold host
• Worked examples
• A one-page checklist
• Comparing against other people's results

Start with the system information block

The header block is context for everything below it. Things worth noticing:

Line	What to look for
Uptime	A fresh VM (minutes) may still be running first-boot tasks (package updates, cloud-init) that depress CPU and disk numbers. A long-lived box has had time for its storage to fill and for neighbours to arrive.
Processor	The model tells you the ceiling. Look it up on the Geekbench Browser CPU chart to see what the chip does on bare metal. Generic names like "QEMU Virtual CPU", "Common KVM processor" or "AMD EPYC Processor (with IBPB)" mean the provider hides the real model; you can only compare by score.
CPU cores @ MHz	Cores is the vCPU count you were given, not necessarily physical cores. MHz is the current clock of one core at the instant the script started, so an idle server legitimately shows 800–1,200 MHz. A low value here is not a defect; a high value under load that does not match the CPU's spec can hint at a hypervisor reporting a fixed nominal clock.
AES-NI / VM-x/AMD-V	Whether the CPU flags are exposed to your VM. "AES-NI Disabled" on a modern CPU means the provider's CPU model mask hides it — expect slower TLS/VPN/disk encryption. "VM-x Disabled" simply means nested virtualisation is not passed through; it is normal on most VPS plans.
RAM / Swap	Geekbench 5/6/7 need roughly 1 GiB free; on 512 MiB–1 GiB plans without swap it fails (the script says so). Swap of 0 on a tiny plan is itself a warning for the disk test too (fio needs memory for its queues).
Disk	The total of all local filesystems. If it is far smaller than advertised, you may be on a container with a thin root, or the data disk is not mounted.
VM Type	KVM, XEN, VMWARE, MICROSOFT = full virtualisation (your own kernel). LXC, OPENVZ = containers sharing the host kernel: CPU and memory limits are cgroup quotas, disk numbers describe whatever storage sits underneath, and some tests may be restricted. NONE = bare metal (or a hypervisor systemd-detect-virt cannot identify).
IPv4/IPv6	If IPv6 is "Offline" you will get no IPv6 iperf table; if IPv4 is offline Geekbench cannot be downloaded and no Network Information appears.

Disk: reading the fio table

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 45.43 MB/s   (11.3k) | 461.52 MB/s   (7.2k)
Write      | 45.52 MB/s   (11.3k) | 463.95 MB/s   (7.2k)
Total      | 90.95 MB/s   (22.7k) | 925.48 MB/s  (14.4k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 840.34 MB/s   (1.6k) | 853.47 MB/s    (833)
Write      | 884.99 MB/s   (1.7k) | 910.31 MB/s    (888)
Total      | 1.72 GB/s     (3.3k) | 1.76 GB/s     (1.7k)

How the table is built (the three facts you need)

1. Every cell comes from the same kind of test: random I/O, 50 % reads and 50 % writes issued simultaneously, 2 worker processes each keeping 64 requests in flight (128 outstanding), direct I/O (O_DIRECT, bypassing the guest's page cache), for up to 30 seconds per block size against a 2 GiB file (512 MiB on ARM/RISC-V). Full details on Tests: Disk (fio).
2. Read ≈ Write is expected. Because the mix is exactly 50/50, fio issues equal numbers of reads and writes, so the two rows are nearly identical by construction. Do not read "my reads are as slow as my writes" into it. A large asymmetry (say 2× or more) is the unusual case and tells you a cache or a throttle is treating one direction differently.
3. Total = Read + Write. It is the device's combined capability under this mixed load. When people quote "a 4k IOPS figure" from YABS they usually mean the Total IOPS; when comparing with vendor spec sheets (which quote pure read or pure write), the per-direction row is the closer analogue, and even that is conservative because the device is doing both at once.

Which row matters for you

Block size	Dominant metric	Represents	Who should care most
4k	IOPS	Small random operations: database rows and indexes, mail queues, web application files, package databases, logging, anything "chatty". Most server I/O is like this.	Databases (MySQL/PostgreSQL/Redis persistence), web apps, mail, game servers, build servers, anything with many small files
64k	both	Mid-size chunks: virtual-disk and filesystem metadata operations, many database engines' page sizes, image thumbnails, cache files. A reasonable "general purpose" indicator.	General web/app hosting
512k	MB/s	Large chunks; approaches sequential behaviour.	Media, backups, large downloads
1m	MB/s	Effectively the device's streaming throughput under mixed load.	Backup targets, video, object storage, large file transfer, "how fast can I restore?"

A quick way to see the character of a disk: 4k Total IOPS tells you how responsive it is; 1m Total MB/s tells you how wide it is. Spinning disks are narrow and slow to respond; SATA SSDs are responsive but capped in width; NVMe is both; network storage is wide-ish but adds latency to every request.

Storage-class fingerprints

Use these to answer "what am I actually on?". Figures are for a single device of the class under YABS's mixed test on a lightly loaded host; RAID arrays, striping, and caches push numbers up, and shared/oversold hosts push them down.

What you are probably on	4k IOPS (Total)	1m MB/s (Total)	Tell-tale shape	Notes
Single spinning disk (HDD)	~100–400	~100–250	4k row is tiny (single-digit MB/s); IOPS do not scale with block size; 1m is only a few times 512k	A 7,200 rpm disk physically manages ~75–150 random I/Os per second per spindle. Values above a few hundred IOPS mean RAID, a cache, or SMR tricks.
HDD RAID (several spindles)	~300–2,000	~200–800	Like HDD but multiplied by the number of disks	RAID-10 of 4–8 disks is a common "storage VPS" backend.
HDD with SSD/RAM write-back cache (RAID controller BBU cache, ZFS SLOG/ARC, bcache, hypervisor cache)	10k–200k	200–1,000	Suspiciously good 4k numbers next to HDD-class 1m throughput; results fall sharply when the test is repeated or lengthened	The 2 GiB test file can fit in a cache. See Caching below.
SATA SSD	~20k–90k	~450–550	1m Total hits a wall around 500–550 MB/s even for Read + Write combined (the SATA bus is ~6 Gbit/s half-duplex)	Published single-device 4k random read figures sit around 90k IOPS (SSD Nodes, 2026); the mixed YABS test typically shows less.
SATA SSD RAID / enterprise SAS SSD	~50k–200k	~800–2,000	Above the SATA ceiling on 1m, IOPS still well short of NVMe	Common on older dedicated servers.
NVMe (PCIe 3.0)	~100k–400k	~1,500–3,500	Both rows large; 1m often exceeds 2 GB/s Total	Published 4k random read figures around 180k per device; a Ryzen/EPYC dedicated server easily shows 300k+ Total.
NVMe (PCIe 4.0/5.0, modern dedicated)	300k–1M+	3,000–12,000	1m Total of several GB/s; 4k Total in the high hundreds of thousands	Typical of 2023+ Ryzen 7000/9000 and EPYC Genoa dedicated boxes.
Network block storage (Ceph RBD, cloud volumes, SAN)	~2k–30k	~100–1,500	Reasonable throughput but modest IOPS; often a flat IOPS plateau that is identical at 4k and 64k (a QoS limit); latency-bound	Every request crosses a network. Many clouds cap IOPS per volume (e.g. 3k baseline on small volumes).
Heavily oversold / contended SSD node	1k–10k	50–300	SSD-class CPU and marketing, HDD-class numbers; wildly different on re-run	Re-run at another hour before concluding.

Two rules of thumb that fall out of the table:

• A 1m Total above ~600 MB/s rules out a single SATA SSD; above ~3 GB/s you are on NVMe or a large array.
• A 4k Total below ~1,000 IOPS on anything sold as "SSD" or "NVMe" is a red flag (contention, throttling, or misdescription), unless the ZFS warning or a dd fallback explains it.

Caching and other sources of inflated numbers

--direct=1 only bypasses the cache inside your VM. Everything below the virtual disk can still cache:

• hypervisor write-back caching (cache=writeback in QEMU, common on budget nodes);
• RAID controller cache with battery backup;
• ZFS ARC/L2ARC (reads) and SLOG (writes) on the host;
• bcache/dm-cache/LVM cache tiers on the host;
• Ceph or SAN caching layers.

Signs that a cache, not the disk, produced your numbers:

Sign	Why it happens
4k IOPS far higher than the storage class suggests while 1m throughput is HDD-class	Small writes are absorbed by a fast cache; large sequential streams exceed its bandwidth or bypass it
Results drop sharply on a second run, or on a run with a larger file	The cache has filled or is flushing to the slow tier
Totals that exceed the physical bus or device spec (e.g. 1.5 GB/s on a "SATA SSD")	Reads served from host RAM
Reads much faster than writes (breaking the 50/50 symmetry)	Read cache (ARC/page cache) with writes going to real disk, or write throttling
Writes much faster than reads	Write-back cache absorbing writes; reads must hit the platters
IOPS collapsing to near zero mid-test and recovering (visible if you run fio by hand)	Cache flush stalls or QoS throttling windows

None of this is cheating by itself — a well-cached HDD array can be a perfectly good product — but it means the headline IOPS will not hold up under sustained load. If sustained behaviour matters, run fio yourself with --runtime=600 --time_based or a test file larger than the host's likely cache (see Tests: Disk (fio) for the exact command YABS uses to start from).

Throttling and QoS limits

Providers increasingly cap IOPS and/or throughput per volume. The fingerprint is a plateau: the same round-ish IOPS at 4k and 64k (e.g. both 3.0k), or the same MB/s at 512k and 1m, with Read and Write each getting exactly half. If the plan documentation lists an IOPS limit, you are simply seeing it. Burst credits (common on cloud volumes) can make a 30-second test look much better than a 10-minute one.

The ZFS warning and other reasons the disk test can mislead

• If you saw Warning! You are running YABS on a ZFS Filesystem and your disk space is too low for the fio test..., treat the disk numbers as invalid. ZFS inflates in-flight write accounting by spa_asize_inflation (default 24×), so a 2 GiB test needs ~48 GiB free; without it results can be up to 10× too low (issue #13).
• If the table is titled dd Sequential Disk Speed Tests, fio could not run. Those numbers are single-threaded sequential, the read side is cache-inflated, and they cannot be compared to fio rows.
• The test measures the partition holding your current directory. On a server with a small system disk and a large data disk, cd to the disk you care about and run yabs.sh -ig.
• fio in YABS reports averages only. It does not show latency percentiles (the 99th-percentile stalls users actually notice); for that, run fio by hand without --gtod_reduce=1 --minimal.
• Results before July 2026 were displayed ~2.4 % low because KiB/s were labelled KB/s (issue #120). Irrelevant for class judgements; relevant if you are comparing very precisely across years.

Network: reading the iperf3 table

iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping
-----           | -----                     | ----            | ----            | ----
Clouvider       | London, UK (10G)          | 1.95 Gbits/sec  | 1.43 Gbits/sec  | 10.7 ms
Eranium         | Amsterdam, NL (100G)      | 2.04 Gbits/sec  | 1.81 Gbits/sec  | 3.52 ms
Uztelecom       | Tashkent, UZ (10G)        | 646 Mbits/sec   | 984 Mbits/sec   | 91.9 ms
Leaseweb        | Singapore, SG (10G)       | 316 Mbits/sec   | 1.05 Gbits/sec  | 177 ms
Clouvider       | Los Angeles, CA, US (10G) | 399 Mbits/sec   | 495 Mbits/sec   | 142 ms
Leaseweb        | NYC, NY, US (10G)         | 620 Mbits/sec   | 1.35 Gbits/sec  | 77.9 ms
Edgoo           | Sao Paulo, BR (1G)        | 383 Mbits/sec   | 304 Mbits/sec   | 213 ms

What the columns mean

• Send Speed — data flowing from your server to the remote (your upload).
• Recv Speed — data flowing from the remote to your server (your download).
• Each value is TCP goodput over 8 parallel streams for about 10 seconds, as measured at the receiving end. Mbits/sec and Gbits/sec are bits: divide by 8 for MB/s (1 Gbit/s ≈ 125 MB/s).
• Ping — a single ICMP echo (ping -c1). One sample; good enough to place the server on the map, not a latency benchmark.
• (Link) — the remote server's advertised port. A "(1G)" remote can never show you more than ~940 Mbit/s however fast your own port is.
• busy — the remote gave no usable result after three attempts (no free slot, connection refused, or 0.00 bit/s). It says nothing about your server. Public iperf servers are shared and often saturated. See Tests: Network (iperf3).

Practical ceilings by port speed

TCP/IP framing overhead means a port never shows its nominal rate in iperf:

Port you were sold	Realistic best case in YABS	Comments
100 Mbit/s	~94 Mbit/s
200/300/500 Mbit/s (shaped)	~95 % of the cap	Shaped ports often show their cap very precisely
1 Gbit/s	~930–950 Mbit/s	The most common VPS port
2.5 Gbit/s	~2.3–2.4 Gbit/s
10 Gbit/s	~9.2–9.5 Gbit/s	Only to a 10G+ remote, and only nearby
25/40/100 Gbit/s	limited by the remote and by distance	YABS's 8 streams can saturate 10G; beyond that you are measuring the far end

Reaching ~90 % of the sold rate to the nearest one or two servers is a pass. Many providers also sell "shared 1 Gbit/s" or "fair-use 10 Gbit/s"; sustained results well below the headline on a lightly loaded node reflect that sharing.

Distance, latency and why far-away numbers are lower

A single TCP stream's throughput is bounded by window size ÷ round-trip time (the bandwidth-delay product). Eight streams help, but 150–250 ms paths (Europe ↔ Singapore, US West ↔ Europe) still cannot fill a 1 Gbit/s port in a 10-second test that includes TCP slow start, and intermediate transit links add their own limits. Expect, very roughly:

Round trip (Ping column)	Typical share of a 1 Gbit/s port seen in YABS
< 20 ms (same region)	85–95 %
20–80 ms (same continent / transatlantic)	50–95 %
80–150 ms (intercontinental)	25–70 %
> 150 ms (antipodal, e.g. Europe ↔ Singapore/Brazil)	15–50 %

So: judge your port by the nearest servers; judge your provider's routing/transit by the far ones. A server in Germany doing 940 Mbit/s to Amsterdam and 300 Mbit/s to Singapore is healthy. A server in Germany doing 300 Mbit/s to Amsterdam is not.

Patterns worth noticing

Pattern	Usual meaning
Send far lower than Recv everywhere	Provider-side upload cap or shaping (a real example: 36 Mbit/s send, 300+ Mbit/s recv on a "premium bandwidth" plan). Check the plan's terms.
Recv far lower than Send everywhere	Inbound shaping, or your network stack/NIC offload issues (common on some virtio setups), or DDoS mitigation inline
Both directions capped at a round number (e.g. 250 Mbit/s)	A shaped port
One location much worse than its neighbours	Far-end congestion or bad peering to that network, not your server
IPv6 much slower than IPv4 to the same server	Different (often tunnelled or less-peered) IPv6 path; or IPv6 MTU/fragmentation problems on the provider's side
Everything busy	Your firewall is blocking outbound non-standard ports (5200–5210, 9204–9240), or the server has no working outbound connectivity, or you are on a NAT VPS with restricted ports
Results fine at 03:00, poor at 21:00	Shared uplink contention on the node or the provider's transit; see Benchmarks Are Snapshots

CPU: reading the Geekbench scores

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 1702
Multi Core      | 3039
Full Test       | https://browser.geekbench.com/v6/cpu/XXXXXXX

Single-core vs multi-core

• Single Core measures how fast one thread runs: one web request, one PHP page, one SQL query, one compile step, one game-server tick. For most VPS workloads this is the number that determines "does it feel fast". It depends on the CPU's architecture and clock speed — and on whether your neighbours are leaving it any headroom.
• Multi Core measures aggregate throughput across all vCPUs. On a VPS it mostly tells you how many real cores you are actually getting and whether they are contended. It scales with core count, so a 2-vCPU plan will never rival an 8-vCPU plan here regardless of quality.
• Full Test links to the public Geekbench Browser page listing every sub-test (compression, image processing, HTML5, ray tracing, compiling, machine learning, etc.) and system details. Anyone with the URL can see it.

The scales (never compare across versions)

Version	Baseline score	Reference system	Notes
Geekbench 4	4,000	Intel Core i7-6600U (Microsoft Surface Book)	Weighted memory heavily; 32-bit x86 capable; no ARM/RISC-V Linux build
Geekbench 5	1,000	Intel Core i3-8100 (Dell Precision 3430)	Scores roughly 75–80 % lower than GB4 on the same hardware
Geekbench 6 (default)	2,500	Intel Core i7-12700 (Dell Precision 3660)	New multi-core method ("shared task") that favours heterogeneous/real-world scaling; multi-core scores are lower than GB5 on many-core chips
Geekbench 7	2,500	AMD Ryzen 7 7700 (Lenovo Legion)	Released July 2026; multi-core redesigned again ("not every task in the real world is multi-threaded")

Within one version, double the score means roughly double the performance. A GB5 score and a GB6 score of the same machine are different units; the rough GB5→GB6 single-core factor is 1.1–1.4 but varies enough to be useless for close comparisons. Source: Primate Labs' Geekbench 6 and Geekbench 7 workload documents.

Orientation: Geekbench 6 single-core landmarks

These are approximate, drawn from Geekbench's public CPU charts and the spread of VPS results posted on LowEndTalk/LowEndSpirit in 2024–2026. A VPS normally lands 10–30 % below the bare-metal chart value for the same CPU (virtualisation overhead, shared caches and memory bandwidth, lower sustained clocks on dense server parts).

GB6 single-core	What it usually is
2,600–3,300+	Current high-clock desktop silicon: AMD Ryzen 7000/9000 (incl. X3D), Intel Core 13th/14th gen. Typical of "Ryzen VPS" and gaming/dedicated plans.
1,800–2,600	Recent server parts at good clocks: AMD EPYC Genoa/Turin (9004/9005), Intel Xeon Sapphire Rapids+/Emerald Rapids, AMD Ryzen 5000, Apple-class ARM; also throttled or shared desktop Ryzen.
1,200–1,800	AMD EPYC Rome/Milan (7002/7003), Intel Xeon Ice Lake/Cascade Lake with turbo, Ampere Altra at the top end; most "premium" KVM plans from 2020–2024.
800–1,200	Intel Xeon Scalable 1st/2nd gen without much turbo, Xeon E5 v3/v4 at good clocks, Ampere Altra typical, Oracle A1, Hetzner CAX; most mid-market VPS plans.
500–800	Older Xeon E5 v1/v2, low-clock many-core parts, busy shared nodes, Raspberry Pi 5-class ARM.
< 500	Atom/Celeron/N-series, very old hardware, heavily oversold or CPU-capped plans, or a host under severe load at test time.

Multi-core is harder to tabulate because it depends on vCPU count. A useful derived number is the multi/single ratio:

Multi ÷ Single	On an N-vCPU VM it suggests
≈ 0.9–1.1 × N	Each vCPU is a lightly loaded, dedicated-ish core
≈ 0.5–0.8 × N	vCPUs are SMT siblings (hyperthreads) and/or there is moderate contention — the norm for most shared plans
< 0.5 × N	Heavy contention, a CPU quota (cgroup cpu.max) smaller than the vCPU count, or GB6/7's deliberately sub-linear multi-core scaling on large N
≤ 1 (multi no better than single) on N ≥ 2	Something is wrong: a hard CPU cap, severe steal, or a quota of roughly one core. A LowEndTalk thread diagnosed exactly this: "you have two CPUs but the multi-core scores lower than the single core, which would seem to indicate ... a high load on this host".

What a low score means

A score markedly below the Geekbench Browser median for the same CPU model has four usual causes, in rough order of frequency:

1. Noisy neighbours / oversubscription — other VMs are using the physical cores. Check top or vmstat 1 during a run: the st (steal) column at 0–1 % is normal; sustained >5 % means the hypervisor is taking your time. Re-run at another hour.
2. CPU limits on the plan — "fair share", burstable or quota-limited plans deliberately cap sustained usage; Geekbench's multi-core phase is exactly the kind of sustained load they clamp.
3. Power/thermal limits on the host — dense server CPUs run well below their boost clock when all cores are busy; cheap desktop boards in a colo cage throttle.
4. Hidden or old hardware — "Common KVM processor" may be a decade-old Xeon.

A score above the chart median is possible on a very idle host or a desktop CPU with aggressive boost.

Caveats specific to YABS's CPU reporting

• The CPU cores @ MHz line is a single sample of the current frequency at script start. An idle server showing 800 MHz is not slow; Geekbench will push the clock up.
• Geekbench 5/6/7 need ~1 GiB of free memory; on 512 MiB–1 GiB plans it fails and YABS prints a hint to add swap or use GB4 (-4). A failed Geekbench is a memory story, not a CPU story.
• On 32-bit x86 only Geekbench 4 runs; on ARM and RISC-V only 5/6/7 (and the RISC-V builds are previews).
• Results are uploaded to Geekbench's public browser; pass -g to skip the CPU test entirely if that is a concern.

Spotting an overloaded or oversold host

Signals, strongest first:

1. Steal time (vmstat 1 10 → st, or top → %st) sustained above ~5 % while the CPU test runs.
2. Geekbench multi ≤ single on a multi-vCPU plan, or multi/single far below the vCPU count.
3. Geekbench single-core 30 %+ below the Browser median for the exact CPU model (and reproducible at different hours).
4. Disk IOPS that swing by several × between runs at different times of day.
5. Network results that are fine to the nearest server at night and poor in the evening.
6. A Processor line that hides the CPU model combined with any of the above.

Any one of these on its own is a question, not a verdict. Two or three together, reproduced on another day, is a pattern you can take to the provider — ideally with the raw YABS outputs (or -w JSON files) attached.

Worked examples

A. Modern NVMe dedicated server (Hetzner AX41-NVMe, Ryzen 5 3600, June 2022, Geekbench 5)

4k   Read 667 MB/s (166.8k) | Write 669 MB/s (167.2k) | Total 1.33 GB/s (334.0k)
1m   Read 1.12 GB/s (1.0k)  | Write 1.19 GB/s (1.1k)  | Total 2.32 GB/s (2.2k)
iperf (1G port): 913–930 Mbit/s both ways to London/Paris/NL; 180–320 Mbit/s recv from the US
GB5: single 1341, multi 7663 (12 threads)

Reading: 334k 4k IOPS and 2.3 GB/s at 1m is unmistakably NVMe (a consumer PCIe 3.0 drive, in RAID-1 here). The 1 Gbit/s port is fully delivered to nearby Europe; transatlantic recv numbers are latency-limited and normal. Multi/single = 5.7 on 6 cores/12 threads — exactly what SMT looks like. Nothing to complain about. (Source: LowEndBox article, June 2022.)

B. Budget KVM VPS, 2 vCPU on a Ryzen 9 7950X3D host (February 2025, Geekbench 6)

4k   Total 90.95 MB/s (22.7k)   |  64k Total 925 MB/s (14.4k)
512k Total 1.72 GB/s (3.3k)     |  1m  Total 1.76 GB/s (1.7k)
iperf: ~2 Gbit/s to London/Amsterdam, 300–1,000 Mbit/s far away
GB6: single 1702, multi 3039

Reading: 1.76 GB/s at 1m says NVMe, but 22.7k 4k IOPS is low for NVMe — this is the signature of shared NVMe with an IOPS limit or heavy neighbour load (the jump from 4k to 64k IOPS rising only modestly while throughput explodes points at per-request overhead/QoS rather than the medium). Network: a 2+ Gbit/s port that is delivered nearby. CPU: 1702 single-core is ~45 % below a bare-metal 7950X3D (~3,000); multi/single = 1.8 on 2 vCPUs is fine. Verdict: a decent budget VPS whose CPU is shared and whose storage is capped — typical for the price, and the kind of thing to re-run at another hour before judging. (Source: LowEndTalk 202693.)

C. "SSD" VPS that behaves like a hard disk (LowEndTalk 201063)

4k   Total 92.76 MB/s (23.1k)   |  64k Total 306 MB/s (4.7k)
512k Total 161 MB/s (314)       |  1m  Total 139 MB/s (135)
GB: multi-core lower than single-core on 2 vCPUs

Reading: 139 MB/s at 1m with lower throughput at 1m than at 64k is HDD-class streaming; 23k 4k IOPS is far above what spindles do, so a cache is absorbing the small I/Os (a classic cached-HDD array). The CPU result (multi < single) independently says the host is overloaded or the VM is CPU-capped. Community diagnosis in the thread: "basically HDD level speed", "run top to see steal and iowait". Verdict: not the product that was described, and worth a ticket.

D. Contabo VPS S SSD vs two competitors (LowEndSpirit 11253, 2025–2026, Geekbench 6)

Plan	GB6 single / multi	4k read	4k write
Contabo VPS S SSD (Nuremberg)	812 / 2431	61 MB/s (~15k)	61 MB/s (~15k)
RackNerd (Los Angeles)	1189 / 1972	144 MB/s	144 MB/s
Hetzner CX22 (Falkenstein)	1204 / 2298	269 MB/s	270 MB/s

Reading: all three are SSD-class and all three are perfectly usable; the comparison shows what the numbers are for — the Contabo plan trades per-core speed and 4k performance for more cores and disk space. As the poster put it, "Contabo's CPU numbers look fine on paper, but that 61 MB/s on 4k random writes is the kind of thing that explains why a database on that box feels sluggish".

E. Storage VPS on HDD RAID (typical)

4k   Total 2.1 MB/s (520)       |  64k Total 28 MB/s (440)
512k Total 180 MB/s (350)       |  1m  Total 310 MB/s (300)

Reading: a few hundred IOPS that barely change with block size, and streaming throughput of a few hundred MB/s — several spindles, no cache in play. Exactly right for a storage plan; wrong for anything sold as SSD. (Illustrative composite of commonly posted results.)

A one-page checklist

Disk

• Is the table titled fio, not dd? Was there a ZFS or free-space warning?
• Which partition was tested — the one you care about?
• 4k Total IOPS: hundreds (HDD) / tens of thousands (SSD or network) / hundreds of thousands (NVMe)?
• 1m Total MB/s: < 250 (HDD or network-limited) / ~500 (SATA) / > 1,500 (NVMe or array)?
• Do 4k and 1m agree on a storage class? If not, suspect cache (4k high, 1m low) or QoS (flat plateau).
• Re-run once at a different hour; are the numbers stable within ~20 %?

Network

• Nearest server(s) at ≥ 90 % of the sold port in both directions?
• Far servers lower in proportion to Ping (normal) or uniformly bad (routing/transit)?
• Send vs Recv symmetric? If not, is a cap documented?
• busy everywhere → check your firewall and outbound connectivity before blaming the provider.

CPU

• Which Geekbench version? Compare only within it.
• Single-core vs the Geekbench Browser median for the same CPU: within ~30 %?
• Multi ÷ Single roughly in line with the vCPU count? Never ≤ 1 on 2+ vCPUs.
• Steal time during the run (vmstat 1) under ~5 %?
• Did Geekbench fail for memory reasons (≤ 1 GiB RAM, no swap)? That is not a CPU result.

Context

• Time of day, uptime, and whether anything else was running on the box.
• Is the Processor model hidden? If so, rely on scores and databases, not the name.

Comparing against other people's results

Because YABS refuses to grade, the community built places to compare:

• Results databases that accept -s uploads — YABSdb, VPSBenchmarks, serverlist.dev, ServerVerify, VPS Host Review — let you filter by provider, plan or CPU model and see distributions rather than single numbers. See Ecosystem and Community.
• The Geekbench Browser itself (the Full Test link) shows how your run compares with other submissions on the same CPU model.
• Forum threads such as LowEndSpirit's "Post some YABS bench here" hold years of results, usually with provider, plan and price attached.

When comparing: match the Geekbench version, prefer results from the same year (hardware and the script both change), and remember that the person posting a result usually chose a flattering moment.

See also

• Understanding the Output — line-by-line explanation of the report
• Benchmarks Are Snapshots — variance, methodology, and how to benchmark properly
• Tests: Disk (fio), Tests: Network (iperf3), Tests: CPU (Geekbench) — exactly what each test does
• Glossary — IOPS, block size, steal time, KiB vs KB, and friends
• Troubleshooting and FAQ