Bandwidth overage dispute, their meter vs my meter differs 30%

Which kernel version, 6.1 or backports?

OP answered: 6.1.0-18-amd64 backports.

Not relevant to the metering dispute, but for the X710 firmware bug: there was a regression in 6.1.0-15 through 6.1.0-19 where the kernel driver would reset the NIC stats block during certain ethtool operations. If Contabo's "remote hands" or automated system ran ethtool for diagnostics, it could zero counters without vnstat noticing (vnstat reads kernel counters, but if the kernel zeroes the hardware counters and vnstat is already using the software copy...)

Actually I need to check this. The bug is in Debian BTS #1052847. Might not apply to X710 specifically, need to verify.

ethtool -S eth0 | grep -i "reset\|error"

Run that, see if any counter shows unexpected zeros.

ethtool -S eth0 | grep -i "reset\|error"

Rx_errors: 0
Tx_errors: 0
Rx_over_errors: 0
Rx_crc_errors: 0
Align_errors: 0
Tx_abort_late_coll: 0
Tx_deferred_ok: 0
Tx_single_coll_ok: 0
Tx_multi_coll_ok: 0
Tx_timeout_count: 0
Rx_length_errors: 0
Rx_long_length_errors: 0
Rx_short_length_errors: 0
Rx_csum_offload_errors: 0
Rx_flow_control_xon: 0
Rx_flow_control_xoff: 0
Tx_flow_control_xon: 0
Tx_flow_control_xoff: 0
Rx_xdp_redirect: 0
Rx_xdp_drop: 0
Rx_xdp_tx_errors: 0
Tx_xdp_xmit_errors: 0

No resets, no errors. Clean card.

MRTG has been running 48 hours now. Comparing to vnstat for same period: MRTG shows 847.3 GB out, vnstat shows 849.1 GB. Within 0.2%. The Pi mirror is working, the TP-Link didn't drop anything significant.

So my measurement is consistent. Contabo's number for same 48 hours from their CSV: 1,187 GB. That's 40% high.

I'm writing the formal dispute now.

Dear sir,

Excellent progress. The MRTG and vnstat agreement within 0.2% is very strong evidence. The Contabo figure 40% higher is clearly systematic error, not measurement noise.

Kindly include in your dispute:

• The 48-hour comparison table, MRTG vs vnstat vs their CSV
• The negative delta rows from their CSV as evidence of processing error
• Request for their specific counter-to-billing algorithm
• Reference to your March 3 reboot as only counter reset event, with vnstat continuity proof

I am suggesting also to check if their billing system uses 32-bit math internally even with 64-bit SNMP counters. I have seen this in Indian telecom billing software — the database field was BIGINT but the aggregation stored procedure used INT for intermediate sum. Overflow at ~4GB per aggregation window, silently wrapping.

Not saying Contabo has this exact bug, but "our system accounts for this" with no transparency suggests they do not wish to reveal implementation details that may be embarrassing.

Regards,

Benchmark Addict If it boots, I benchmark it. Numbers over vibes.

0.2% vs 40%. That's not a vibe, that's a bug.

I ran a quick check: if their system uses 32-bit intermediate for rate calculation, and your 48-hour window had any 5-minute interval over 4GB (which at 1G is only ~34 seconds of line rate), the wrap would silently lose 4GB per overflow. Over 48 hours with variable traffic, easy to accumulate 40% phantom data.

Your MRTG at 60s would be less vulnerable, but still possible. The real fix is 64-bit throughout, which they claim to have at the SNMP layer but maybe not downstream.

I benchmarked this once: wrote a program to simulate 32-bit vs 64-bit counter aggregation with real pcap data. 32-bit intermediate lost 12-60% depending on burstiness. Bursty traffic = more wrap events = more error.

Contabo traffic is probably bursty. Your usage pattern?

Web server with video content, so yes: bursty. Peaks during EU evening, quiet overnight. Exactly the pattern that would trigger 32-bit intermediate overflow repeatedly.

I checked their CSV more carefully. The negative deltas aren't random, they cluster around the evening peaks. My hypothesis: high traffic interval, 32-bit intermediate wraps, their "accounting" sees a negative, applies some broken correction (maybe absolute value, maybe drop and interpolate), and the result is inflated.

I'm going to test this. I'll write a script that simulates their 300s aggregation with 32-bit intermediate on my MRTG 60s data, see if I can reproduce ~40% inflation.

If I can reproduce it, that's proof it's their bug not my measurement.

Electronics tech who fell into hosting backwards

Please publish that script if it works. This affects more than just Contabo — anyone using 32-bit math in billing pipelines is vulnerable, and nobody talks about it because "our meter is authoritative."

I fell into hosting from electronics, and this smells like a classic digital design error: the ADC (SNMP poller) is fine, the display (billing system) is fine, but the accumulator between them rolls over. Happens in power meters too, utilities get sued for it.

Your MRTG/vnstat cross-check is basically calibrating your own reference meter. Smart. Most people don't bother, just pay.

Following for script and results.

12ms to Nuremberg, 180ms to everywhere I actually need.

Stockholm to Contabo Nuremberg is 28ms, I've considered them for backup. Not anymore.

This thread is a masterclass in why cheap bandwidth metering is expensive. Your time, the MRTG setup, the dispute, the script — all because they wouldn't run 64-bit throughout or be transparent about their math.

I pay for transit at Netnod and the metering is via sFlow from the router, sampled but with 64-bit counters in the export. Never had a dispute because the numbers are obviously correct, and when I asked for methodology they sent me the router config.

Contabo could do this. They choose not to. That's the real price of "cheap."