GDATA’s one-year server sponsorship for iNut: strong CPU/RAM, storage by tier

Infrastructure reviews often jump from a CPU name and a few benchmark numbers to a verdict that a server is simply “fast” or “slow”. That skips the part that matters in an edge system: which workload runs on the machine, whether the network stays predictable, which storage tier is included, how quickly operators can recover, and where the next resource can be attached.

iNut therefore treats the GDATA 8.17 host as a lab component, not a benchmark trophy. We put it beside 6.18 — a customer VPS — and 8.18 — an on-site i3 mini PC — to answer a practical question: where does a server with very strong CPU/RAM but roughly 3,000 IOPS of included storage belong in an iNut system?

30s

The 30-second read

A fast scan before the detailed benchmark.

1. 01SINGLE-CORE8.17 scored 400.37, 30.8% above 6.18 and 134.6% above the i3 8.18.
2. 02MULTI-CORE1,596.43, almost twice 6.18 and more than 3.5× the i3 mini PC.
3. 03RAM70,017.64 MB/s read and 41,581.12 MB/s write — a clear lead.
4. 04STORAGEmixed random 4K reached 3,042.04 IOPS, closely matching the 3,000-IOPS tier; this is not a claim that the disk is generally fast.
5. 05RECOMMENDATIONUse 8.17 for APIs, control plane, telemetry, CI/CD and edge services; mount a suitable volume for write-heavy databases or logs.

The scripts in ~/review-server warm up each host and report the median of three samples. CPU uses single- and multi-thread sysbench; RAM uses sequential read/write; disk uses fio mixed random 50/50 at 4K, 64K, 512K and 1M, plus a sequential dd write. Fio runs direct I/O, libaio, iodepth 16 and a 2 GiB test file.

The baseline is not perfectly isolated. 6.18 is nearly full, its swap is exhausted and its pre-test load was 2.13 on four vCPUs; 8.18 also had swap in use. We report those warnings rather than hiding them: the result is a snapshot of each host’s state, not a sterile lab claim.

8.17 reports an Intel Xeon Platinum 8180 @ 2.50 GHz, while 6.18 reports a generic QEMU Virtual CPU version 2.5+. The difference appears immediately: 8.17 is 30.8% ahead of 6.18 in single-core and 94.4% ahead in multi-core; versus the i3 mini PC, the gaps are 134.6% and 252.9%.

That fits iNut’s workload: APIs, workers, gateways and short data-processing jobs benefit directly from CPU and memory speed. A machine does not need the highest vCPU count on paper if each request completes quickly and memory pressure stays low. With 8.17, the same four-vCPU envelope gives the workload more headroom.

This is the part worth stating plainly. 8.17 reached 3,042.04 IOPS in mixed random 4K, 108.17 MB/s at 64K, 98.33 MB/s at 1M, and 24.2 MB/s in the sequential dd write. 6.18 reached 30,672.52 4K IOPS and 421 MB/s sequential write; the i3 8.18 reached 50,502.42 4K IOPS.

If this were only a leaderboard, 8.17 would lose on disk. But 3,042 is almost exactly the included 3,000-IOPS tier: the measurement is about 101.4% of the nominal level. That is an intentional storage tier, not evidence that every GDATA disk is slow. We do not call it a fast SSD; we call it the tier we received.

Nguyễn An Hưng’s 2024 Gdata.com.vn VPS review is worth reading because it discloses the sponsorship and still records the negatives. The post described a VMware VPS with a Xeon E5-2698 v3, six cores, 8 GB RAM, roughly 300 Mbps and lower-than-expected FIO results. It also criticized the control panel at the time: no visible reboot/reinstall workflow, no 2FA, and limited account/network tooling.

iNut does not dismiss those observations. They are useful for that VPS, that account and that moment in 2024. The part we challenge is treating a snapshot as a permanent verdict on every GDATA server. The current 8.17 host reports a Xeon Platinum 8180 rather than the generic QEMU CPU seen on 6.18; CPU and RAM are materially stronger, while the storage tier is openly represented by 3,000 IOPS and measures 3,042.04. This is a different configuration and should be measured again.

At the same time, a current dashboard should not erase old criticism. 2FA, VPN allowlisting, network status, a knowledge base and support quality need to be checked per account, tier and date. This article only records that iNut could use the dashboard, reinstall the OS quickly, manage network rules and assign a public IP for an edge workload. Those are field observations, not benchmark results or SLA claims.

The current suite did not run iperf3 or a long-duration network test, so we do not turn 500 Mbps into an independently measured result. It is a committed/observed rate during iNut operations on a Vietnam-hosted server. For edge work, predictable connectivity to gateways, clear rules and a directly assigned public IP can matter more than a few hundred CPU points that the service never uses.

What iNut values in 8.17 is operational: the dashboard allowed a quick OS reinstall, network rules were understandable, and the host had a public IP that could expose an edge agent under policy. Low-cost VPS plans often add NAT or limited rule control; when a factory gateway, camera, PLC or distributed agent must send data inward, that becomes a real constraint. Public IP still requires firewalling, allowlists, SSH keys, logging and a minimal open surface.

After one measurement pass, iNut’s answer is clear: 8.17 is a valuable CPU/RAM host for edge projects and processing services. Xeon Platinum 8180, 70 GB/s RAM read and a 1,596 multi-core score create a large gap over the QEMU-based 6.18 VPS and the i3 mini PC 8.18. Storage does not try to win: 3,042 IOPS tracks the included 3,000-IOPS tier, which is reasonable for the OS and light services but not a reason to make it a database/log node.

What makes iNut want to keep using the machine is not just the benchmark. A Vietnam-hosted server with a predictable committed link, a public IP and clear rules, a dashboard that can reinstall the OS quickly, and an option to attach a suitable disk maps well to our deployment style: data starts at the edge, the central API orchestrates, and heavy storage sits in the right tier.

The original Nguyễn An Hưng review remains a useful reference because it asks the hard questions. iNut’s answer after this measurement is: look at CPU, RAM, network, storage tier and operations together — then put each workload in the right place.

If you are building an IoT/edge system that needs a central API, a Vietnam-based ingestion gateway or a worker tier, iNut can share the practical configuration and volume-splitting approach behind this test.