Netcup Performance Architecture Analysis: EPYC 9645 Zen 5, DDR5 ECC, NVMe & AS197540 Routing

When evaluating cloud servers, inexperienced buyers look only at vCPU count ("4 vCPUs") and clock speed ("2.4 GHz"). Seasoned systems architects look at the underlying silicon microarchitecture and cache topology. A single dedicated Zen 5 core on an AMD EPYC 9645 easily outperforms two oversubscribed Intel Xeon Broadwell/Skylake vCPUs still circulating in legacy public clouds.

In Netcup’s Generation 12 and 12.5 Root Server fleet (from the 2-core RS 500 G12.5 at €10.86/mo net / €12.93/mo gross and 4-core RS 1000 G12.5 at €18.26/mo net / €21.73/mo gross up to the 16-core RS 8000 G12.5 at €124.72/mo net / €148.42/mo gross), host hypervisors are powered by the AMD EPYC 9645 (Turin family, Socket SP5). Each processor packages 12 Core Complex Dies (CCDs) around a central I/O die, providing 96 physical Zen 5 cores and 384 MB of shared L3 Victim Cache (32 MB per 8-core CCD).

Because an 8-core CCD shares a unified 32 MB L3 cache slice with sub-12-nanosecond intra-CCD core-to-core latency, pinning a 4-core RS 1000 G12.5 or 8-core RS 2000 G12.5 within a single CCD boundary keeps inter-thread mutex locks and Go/Tokio work-stealing queues strictly on-die, avoiding cross-socket NUMA traversal penalties. Key microarchitectural advances inside each Zen 5 core include:

• ▪ Dual 4-Wide Decode & 8-Wide Dispatch Engine: Widens the instruction execution window and reduces pipeline stalls on branch-heavy application code (such as PHP 8.3/8.4 JIT, Node.js V8, and Python 3.12+ interpreters).
• ▪ Full 512-Bit Native AVX-512 Data Path: Whereas Zen 4 (EPYC 9634 in G11) executed 512-bit vector instructions by double-pumping 256-bit execution units over two clock cycles, Zen 5 executes full 512-bit vector operations in a single cycle—dramatically accelerating pgvector embeddings, local LLM/ONNX inference, ChaCha20-Poly1305 encryption, and zstd compression.
• ▪ 48 KB 12-Way L1 Data Cache + 1 MB 16-Way L2 Cache per Core: Reduces L3/DRAM round-trips for hot database B-tree index pages.

Inside a Netcup KVM guest, your disk is exposed through the QEMU paravirtualized SCSI controller (virtio-scsi) or block driver (virtio-blk). Because the host hypervisor manages physical NVMe queue submission and RAID striping on the underlying enterprise SSDs, running complex mechanical-disk I/O schedulers (like bfq or kyber) inside your Linux guest adds unnecessary CPU overhead.

Furthermore, because Netcup G12.5 Root Servers map your virtual disk directly to chassis-local PCIe Gen4/Gen5 NVMe arrays rather than a distributed network block cluster (such as Ceph over 25GbE), synchronous database commits (fsync / fdatasync) bypass network serialization entirely. On our Nuremberg RS 1000 G12.5 testbed, direct 4K reads and synchronous journal commits routinely settle between 120 and 210 microseconds.

For optimal random 4K latency on Ubuntu 24.04 LTS and Debian 12 running on Netcup G12.5 NVMe storage (across both RS 500–8000 G12.5 and VPS 500–8000 G12.5), verify that your guest block device uses none (for virtio-blk multi-queue) or mq-deadline (for virtio-scsi), and ensure weekly fstrim.timer discard operations are active so the host storage array can reclaim unallocated blocks cleanly.

# 1. Verify block device driver, discard (TRIM) granularity, and active I/O scheduler
lsblk -o NAME,SIZE,TYPE,FSTYPE,DISC-GRAN,DISC-MAX,SCHED

# 2. Ensure weekly fstrim timer is active for thin-provisioned KVM storage
sudo systemctl enable --now fstrim.timer
sudo systemctl status fstrim.timer --no-pager

# 3. Measure true non-cached 4K random disk latency safely (10 requests, read-only)
# (Install ioping first: sudo apt install -y ioping)
sudo ioping -c 10 -s 4k -D /var/lib

4 KiB <<< /var/lib (ext4 /dev/sda2): request=1 time=184.2 us (warmup)
4 KiB <<< /var/lib (ext4 /dev/sda2): request=2 time=142.8 us
--- /var/lib (ext4 /dev/sda2) ioping statistics ---
9 requests completed in 1.31 ms, 36 KiB read, 6.87 k iops, 26.8 MiB/s
min/avg/max/mdev = 128.4 us / 145.6 us / 179.1 us / 16.2 us

Netcup operates its own autonomous network (AS197540, netcup GmbH) rather than reselling single-homed budget transit. In Europe, traffic from Nuremberg, Vienna, and Amsterdam is routed across redundant dark-fiber rings directly into major European internet exchanges—including DE-CIX (Frankfurt), VIX (Vienna), and AMS-IX (Amsterdam)—alongside Tier-1 transit providers (Arelion/Telia, Lumen, GTT, Cogent, and Anexia’s global backbone AS42473 for Manassas US and Singapore).

At the KVM guest layer, Netcup binds multiple TX/RX packet queues (virtio-net multiqueue) matching your assigned vCore count (e.g., 4 combined queues on RS 1000 G12.5 and 8 combined queues on RS 2000 G12.5). This allows the Linux kernel’s Receive Side Scaling (RSS) and irqbalance daemon to distribute network soft-interrupts (NET_RX / NET_TX) evenly across all CPU cores rather bottlenecking CPU0 during high-packet-rate TLS termination.

To saturate the 2.5 Gbit/s port on a G12.5 Root Server or G12.5 VPS (or 1 Gbit/s port on VPS pico/nano G11.5s) across high-bandwidth-delay-product (BDP) paths (such as Nuremberg to US East or Singapore), we strongly recommend enabling Google’s TCP BBR (tcp_bbr) congestion control algorithm and Fair Queue (fq) packet pacing inside /etc/sysctl.d/99-netcup-bbr.conf.

# Inspect combined TX/RX multiqueue channels on your primary virtio network interface
ethtool -l $(ip -o -4 route show to default | awk '{print $5}')

# Enable Fair Queue (fq) + TCP BBR congestion control for 1 Gbps / 2.5 Gbps ports
cat << 'EOF' | sudo tee /etc/sysctl.d/99-netcup-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = bbr

Out-of-the-box Linux distributions ship with virtual memory dirty-page ratios (vm.dirty_ratio = 20, vm.dirty_background_ratio = 10) designed for workstations rather than high-memory DDR5 KVM servers. On a 32 GB (VPS 4000 / RS 4000) or 64 GB (VPS 8000 / RS 8000) node, allowing 6.4 GB to 12.8 GB of dirty pages to buffer in RAM before flushing to the virtio-scsi queue can cause micro-stutters during PostgreSQL checkpoint bursts.

Lowering vm.dirty_background_bytes to 64 MB and vm.dirty_bytes to 256 MB forces the Linux kernel to flush writes smoothly and continuously to the underlying NVMe array, keeping p99 database query latency flat.

For PostgreSQL 16 and 17 instances running on G12.5 Root Servers, we also recommend setting shared_buffers to 25% of total RAM (2GB on RS 1000, 4GB on RS 2000), effective_cache_size to 75% of RAM, random_page_cost = 1.1, and effective_io_concurrency = 200. Because the EPYC 9645 exposes native AVX-512 instructions, PostgreSQL automatically utilizes hardware-accelerated instructions for WAL CRC32C checksums and pgvector HNSW cosine distance calculations.