How to Test Your Actual Internet Speed vs What Your Provider Guarantees

Your provider says you have a 20Mbps dedicated connection. You run a speed test and it shows 19.8Mbps. Everything looks fine.

Three hours later, your team is complaining that video calls are dropping, the ERP system is timing out, and the VoIP phones sound like they are underwater.

The speed test said everything was fine. So what is happening?

The answer is that the speed test was not measuring what actually matters to your business. This article explains what it was measuring, what it was missing, and how to properly evaluate whether your internet connection is performing as your provider guaranteed.

What Speedtest.net Actually Measures

Speedtest.net and most consumer speed test tools measure the speed between your device and the nearest test server — which is almost always a Content Delivery Network (CDN) node located close to you, often within the same country or even the same city.

This is not the same as measuring your real internet performance.

When your staff use cloud applications, send emails to international clients, connect to overseas servers, or make VoIP calls, the data travels much further than the nearest CDN node. It crosses your local network, exits through your ISP's infrastructure, traverses the backhaul, crosses international peering links, and reaches servers that may be in Europe, the United States, or elsewhere.

The speed to the nearest CDN node tells you nothing meaningful about any of that journey. A connection can show 50Mbps on Speedtest.net and still perform terribly for real business applications because the problem is latency, not bandwidth — and it is occurring somewhere between Ghana and the overseas server your application depends on.

The Four Metrics That Actually Matter

Bandwidth is the one metric most people focus on. It measures how much data can be transferred per second. It matters — but it is the least important of the four metrics for most business applications.

Latency is the time it takes for a packet of data to travel from your device to a server and back. Measured in milliseconds. For VoIP, video conferencing, and any real-time application, latency is critical. High latency makes calls sound delayed, video freeze, and interactive applications feel sluggish. A connection with 200ms latency will feel slow regardless of how much bandwidth it has.

Packet loss is the percentage of data packets that fail to arrive at their destination. Even 1% packet loss is noticeable on VoIP. At 3–5%, calls become unusable and file transfers slow dramatically. Packet loss is invisible to most speed tests but devastating to business productivity.

Jitter is the variation in latency over time. A connection with consistent 50ms latency is manageable. A connection where latency varies between 10ms and 200ms unpredictably will produce poor VoIP quality and unreliable real-time applications — even if the average latency looks acceptable.

Why Your Provider's Monitoring Misses These

Most ISPs monitor from their Network Operations Centre to your demarcation point. This tells them whether the physical connection to your building is active. It does not measure latency, packet loss, or jitter as experienced from inside your premises to the real internet.

A connection can have perfect uptime — the link is technically "up" — while simultaneously having high latency, packet loss, and jitter that make it effectively unusable for business applications. The NOC sees green. Your staff see a productivity problem.

This is the fundamental gap between "the connection is up" and "the connection is performing."

How to Test Properly

*Test 1: Latency and packet loss to a real internet endpoint*

Use PingPlotter (free version available) to run a continuous trace to a server outside Ghana — Google's DNS server at 8.8.8.8 is a reasonable target, or better yet an international server your business actually uses.

Run the test for at least 30 minutes during peak business hours — not at 6am on a Sunday. Watch the latency graph. A well-performing business connection should show consistent latency below 100ms to international endpoints. Watch for spikes and for packet loss indicators.

*Test 2: True throughput to an overseas server*

Use iperf3 to test throughput to a server outside Ghana. iperf3 is a command-line tool that measures actual TCP/UDP throughput between two endpoints — not to a CDN node, but to a real server you control or trust.

If you do not have access to a remote iperf3 server, public test servers are available. The key is to test to a server that represents where your actual business traffic goes — not the nearest node.

*Test 3: VoIP quality simulation*

Tools like VoIP Spear or similar services simulate VoIP traffic and report a MOS (Mean Opinion Score) — an industry-standard measure of call quality. A score below 3.5 indicates noticeable quality issues. Run this test during business hours when the network is under real load.

*Test 4: Application performance under load*

The most realistic test is observing how your actual applications perform when your network is under normal business load — multiple users, video calls running, cloud applications active. If performance degrades noticeably during peak hours, the issue is likely congestion or bufferbloat rather than raw bandwidth.

What Bufferbloat Is and Why It Matters

Bufferbloat is a specific performance problem that causes high latency and jitter under load — even when bandwidth appears plentiful. It occurs when network equipment buffers large amounts of data rather than managing the queue intelligently, causing significant delays for latency-sensitive traffic like VoIP and video.

A connection suffering from bufferbloat will show excellent bandwidth on a speed test — because the speed test fills the buffer and measures throughput — while simultaneously performing terribly for real-time applications.

The fix is Active Queue Management (AQM) — specifically algorithms like CAKE or fq_codel deployed on the router managing your connection. These algorithms keep queue lengths short and prioritise latency-sensitive traffic, dramatically improving real-world performance without requiring more bandwidth.

What Good Performance Looks Like

As a reference point for business connections in Ghana:

Metric · Acceptable · Good · Excellent

Latency to international endpoint · < 150ms · < 100ms · < 60ms

Packet loss · < 0.5% · < 0.1% · 0%

Jitter · < 30ms · < 15ms · < 5ms

Throughput vs contracted speed · > 80% · > 90% · > 95%

If your connection is consistently outside the "acceptable" range during business hours, you have a performance problem regardless of what the speed test shows.

What to Do With the Results

If your testing reveals consistent latency spikes, packet loss, or throughput well below your contracted speed during business hours, you have evidence of a performance problem. Document the results with timestamps — multiple tests over several days — before approaching your provider.

A provider who takes SLAs seriously will investigate when presented with evidence. A provider who dismisses documented performance data, or who asks you to run Speedtest.net and declares the connection fine, is telling you something important about the relationship.

The IJA Approach

IJA installs a Raspberry Pi at each managed customer's premises. It runs PingPlotter continuously, measuring latency, packet loss, and jitter to international endpoints around the clock. It also runs scheduled iperf3 tests to an AWS server in London — measuring true internet throughput, not CDN performance.

Every customer receives access to their own Grafana dashboard showing this data in real time. When thresholds are crossed, our team is alerted automatically. We investigate before you call.

That is the difference between monitoring and managed monitoring.

IJA Technologies provides managed network services with contractual SLAs backed by continuous monitoring from your premises to the internet. Talk to us about your network.