netcup Nuremberg vs OVH US West (Hillsboro): International Connectivity Tested

This was first posted on my SunAI forum. Updates and additions will go on the forum first; feel free to leave questions in the original thread.

I happen to have two servers in almost opposite corners of the world: one netcup server in Nuremberg, Germany（AS197540）, and one OVH dedicated server in Hillsboro, Oregon, USA（AS16276, KS series）. I compared their international connectivity, and the results were more interesting than I expected—not "which is better," but two completely different networks.

Test Method

Comparing RTT directly is pointless when one server is in Europe and the other is on the US West Coast. That measures the shape of the Earth, not network quality. So I did two things:

1. Same targets, same time window: 33 global targets（Vultr / Linode locations + OVH）, with 20 ICMP packets per target, tested simultaneously from both servers.
2. Normalize to a path inflation ratio: Calculate the theoretical minimum RTT from the great-circle distance（speed of light in fiber ≈ 200km/ms, so round-trip time is 距离km / 100 ms）, then use 实测 ÷ 理论 to get a ratio that removes the geographic factor.

Reference ranges: 1.31.5 indicates a good direct route, 1.51.8 is normal, >2.2 indicates a clear detour.

The overall scores first: netcup's global average ratio was 1.93, OVH's was 1.87. Essentially a tie—the differences are all in the regional breakdown.

Regional Results

RTT is in ms; parentheses show the path inflation ratio.

Region	netcup Nuremberg	OVH US West	Notes
Frankfurt / Amsterdam	3.5 / 10.4	151 (1.80) / 154 (1.92)	netcup's home turf
London / Paris	13.9 / 12.0	141 (1.78) / 146 (1.76)
Stockholm / Warsaw	21.0 / 20.7	170 / 173
New York(NJ)	85.0 (1.32)	71.2 (1.82)	netcup's transatlantic ratio is its best in the table
Toronto / Atlanta	105 / 108	69.8 / 72.9
Chicago / Dallas	115 / 127	43.8 / 54.8
Silicon Valley / Seattle	141 / 165	17.0 / 4.8	OVH's home turf
Tokyo	245 (2.64)	98.9 (1.27)	Best ratio in the table
Osaka / Seoul	231 (2.51) / 243 (2.86)	141 (1.73) / 156 (1.85)	East Asia is a clear weakness for netcup
Singapore	182.8 (1.81)	184.5 (1.41)	Almost an exact tie
Bangalore / Delhi	145 / 154	268 / 280	netcup leads by a wide margin
Tel Aviv	56.6	211
Johannesburg	178	304	A 126ms gap
Melbourne	293	160 (1.23)
Sydney	282	296 (2.41)	This OVH route has a problem; see below
Mexico City	147	69.5
São Paulo / Santiago	216 / 219	190 / 215	OVH has a slight edge

Packet loss: 0% across the table for both servers. Jitter: mostly around 0.05ms, with very clean links on both. Nothing to distinguish them here; both pass.

Backbone Architecture: Two Completely Different Approaches

This is the root of the differences. I used mtr -znr to inspect the AS paths on several key routes.

netcup —— Direct Peering at Internet Exchanges

Its upstreams are ANEXIA（AS47147）+ Core-Backbone（AS201011）. The key advantage is its Frankfurt presence, with plenty of direct peering at DE-CIX:

Destination	Path	Result
US East	Core-Backbone → US East exchange → target	8 hops, 85ms
Singapore	Core-Backbone → local Singapore exchange → target	8 hops, 181ms
Johannesburg	DE-CIX → Workonline (AS37271) → target	178ms
Sydney	DE-CIX → Telstra Global (AS4637) → Telstra (AS1221)	281ms
Tokyo	Telia (AS1299) throughout	245ms

For Africa, Oceania, and Southeast Asia, it is essentially "one handoff at DE-CIX to the regional backbone." That explains its strong results in the Middle East / Africa / India. The weakness is equally clear: no direct route to Asia; East Asian traffic relies entirely on detours through Telia. There is also visible hairpinning within Telia（intermediate-hop latency jumps back and forth from 161 → 254）.

OVH —— Long-Haul Transport on Its Own Backbone

OVH carries traffic a long way within its own AS before handing it off:

Destination	Path	Result
Frankfurt	AS16276 carries traffic all the way from Seattle to Frankfurt, only handing it off at DE-CIX on hop 16	151ms, on its own network throughout
Tokyo	US West egress hands off to Telia (AS1299)	99ms, very clean
Melbourne	US West egress → Vocus (AS4826) → AAPT (AS7545)	160ms
Johannesburg	AS16276 → LINX London → Workonline (AS37271) → South Africa	304ms, detour through Europe
Singapore	Telia (AS1299), with hairpinning along the path	184ms

The benefits of its own backbone are control over routing, extremely low jitter, and full control of the transoceanic segment. The downside is that destinations without direct connectivity, such as Africa, require a detour back through Europe before heading south.

An Actual Problem I Found Along the Way

OVH → Vultr Sydney came in at 296ms, with a ratio of 2.41—its worst in the table. Yet Melbourne, also in Australia, was only 160ms（ratio 1.23, one of the best in the table）. Looking at mtr:

11. AS4826  114.31.192.33     166.5   ← Vocus, already in Australia, normal latency
14.         203.131.59.34     170.0   ← Still 170ms
15. AS4739  182.239.245.74    309.1   ← A sudden 139ms increase at this hop

Latency was still 170ms on arrival in Australia, then the final stretch through AS4739 added 139ms. Either that segment took a detour, or the return path for the destination prefix went another way. Australia as a whole is not the problem; this specific route is. If you serve users in Australia, I would suggest Melbourne, or retesting with a different Sydney target.

Conclusion

The choice is clear based on your target audience:

• Europe / Middle East / Africa / India → netcup. The gaps are substantial: Tel Aviv 57 vs 211, Bangalore 145 vs 268, Johannesburg 178 vs 304
• North America / Japan and South Korea / Oceania / Mexico → OVH US West. Tokyo 99 vs 245, with a ratio of 1.27
• Southeast Asia（Singapore） → A complete tie, 182.8 vs 184.5; either location works
• South America → OVH has a slight edge, but no major gap

Neither server has "poor international connectivity"—0 packet loss, extremely low jitter, and average ratios around 1.9 are all normal. They complement each other: one covers EMEA + India, the other covers the Americas + East Asia + Oceania. If your budget allows running both, this pairing actually provides quite comprehensive global coverage.

A Few Methodology Caveats

• Do not take ratios for short-distance targets too seriously. For entries such as Seattle at 238km, Frankfurt at 187km, and Warsaw at 762km, fixed overhead makes up too much of the RTT and inflates the ratio. Just look at absolute RTT.
• Intermediate-hop latency in mtr includes that hop's return path, so it is normal for a hop to show higher latency than later hops. Only the final hop's value is reliable.
• This is a single snapshot. Transoceanic routes can vary considerably between peak and off-peak hours. Before drawing conclusions, it is best to run the test again 12 hours later.
• I did not test routes to China this time. Cross-border QoS and time-of-day differences across China's three major carriers are a separate topic; mixing them in would muddy the conclusions.

If you have similar servers, feel free to add your data to the original forum thread. I would especially like to see results from other netcup locations（Vienna / Mannheim）and other OVH regions（BHS / GRA）.

---

Join the Discussion on the Forum

This article was first published on the SunAI forum: netcup Nuremberg vs OVH US West(Hillsboro): International Connectivity Test Comparison

This is a single snapshot. If you have servers in other netcup locations or OVH regions（BHS / GRA）, please add your data to the original thread.

SunAI is a tech community I run myself. I post VPS reviews, network tuning, website setup, and AI tool content there first. Feel free to stop by.