How fast is IBM Cloud from your place?

Short answer: only a test from your own network tells you how fast a region feels to you.

Most "cloud ping" sites and every provider's looking glass run the test from their servers, which sit in data centers on premium links. That shows how fast one data center reaches another. It misses the part you actually feel: your home or mobile line, your ISP's backbone, its international links and how crowded they are tonight.

Me2Cloud sends every request from your browser, so the result includes all of it: Wi-Fi, router, ISP, the route your ISP picks, and the evening rush.

1. A warm-up request sets up DNS, the TCP connection and TLS encryption. Its time is shown but not counted.
2. The browser then sends 5, 10 or 20 more requests to the same host over the same connection. Each one costs a single round trip, plus a little processing time on the provider's server.
3. Each provider gets the request type we confirmed keeps the connection open: GET for AWS, Azure, Google Cloud, DigitalOcean and Scaleway; HEAD for Oracle, IBM Cloud, Alibaba Cloud, Tencent Cloud, Volcengine, Baidu AI Cloud, Naver Cloud, Huawei Cloud, Linode, Vultr, OVHcloud, IONOS Cloud, Aruba Cloud, Leaseweb, Gcore and Yandex Cloud (they close the connection after a GET, which would triple every sample); and a CORS GET for Hetzner, whose page the browser would otherwise cut off, dropping the connection.
4. You get the median (the typical value), the average, P90 (9 in 10 samples are at or below it), jitter (how much consecutive samples differ, on average) and timeout rate (the share of samples with no answer before the time limit).
5. The tier comes from the median: T0 GOATed ≤ 30 ms, T1 Top tier ≤ 80 ms, T2 Solid ≤ 150 ms, T3 NPC ≤ 250 ms, and T4 Cooked above that. "Our picks" are ranked by median + 2 × jitter + a timeout penalty, so a steady 60 ms beats a jumpy 45 ms.

• It takes the same road as your traffic. Websites, APIs, tunnels on port 443, game logins and downloads all use TCP. Many ISPs queue, slow down or route ICMP separately, so ping can look fine while pages crawl, or the other way round.
• It isn't throttled away. Routers and clouds often limit or drop ICMP. A public HTTPS endpoint always answers.
• It includes your real setup. DNS, the choice of IPv4 or IPv6, proxies and accelerators all apply to browser traffic, so you measure what you'd actually get.
• The trade-off: each sample also includes a small, steady server processing time. We measured 0–5 ms for AWS, about 8 ms for Alibaba Cloud and about 20 ms for Huawei Cloud OBS. Above 100 ms it doesn't matter; for very close regions the number reads a little higher than ping.

• Home networks are busiest from about 20:00 to 23:00, and international links even more so. A region that's T1 at noon can drop to NPC at night.
• Test once during the day and once at peak. Runs taken at peak are tagged "peak hour", and you can switch between runs in the results.
• Pause big downloads, streaming and cloud sync while testing. A cable beats Wi-Fi; on Wi-Fi, stay close to the router.
• On mobile data, results change with signal strength. Test where you'll actually use the service.

• Shortlisting regions before you buy a server, a game server or a CDN origin.
• Comparing regions of one provider, or different providers in the same city.
• Checking whether stability (jitter, timeout rate) is good enough for gaming, video calls, remote desktop and SSH.
• Seeing how your proxy, accelerator or new internet plan really performs: test once with it, once without.
• Putting your own server or CDN next to the big names with a custom endpoint.

• It covers one location. It measures your line, not your users'. Ask a few of them to run it, then export and compare.
• It tests the provider's public endpoint, not your future server. We test each provider's public API or storage endpoint in the region. Servers in the same region usually share that network, but premium routes (for example CN2, BGP vs single-carrier lines, Lightsail vs EC2) can differ.
• No bandwidth, no UDP, no traceroute. It measures round trips, not download speed or UDP game traffic, and it doesn't show the hops in between.
• The browser adds some noise. Extensions, proxies, VPNs and busy tabs all affect results. Close heavy tabs and keep this page in front.
• A few endpoints may be unreachable from some countries.

• Your results are not uploaded, and there's no account. Only when you press Share is the result stored at 1ms.dog as a short link with a preview image, so chat apps can show it.
• Every test request goes straight from your browser to the provider. Open the Request log above, or your browser's developer tools (Network tab), to see each one.
• Network info comes from Cloudflare: this site's own /_ms/me answers first, and speed.cloudflare.com/meta and /cdn-cgi/trace have the final say, because they take the same path as the tests. The optional WebRTC check asks stun.cloudflare.com for your UDP exit address; you can turn it off in Settings.
• The IPv4/IPv6 check also asks ipify.org and ident.me, outside Cloudflare, so a network that blocks one of them isn't reported as having no IPv6.
• If the page hits an error, it sends the error message, the page address and your browser version back to this site so we can fix it. Using Share also counts, anonymously, which steps were used. Neither includes your results.
• Settings, custom endpoints and recent runs stay in this browser. Holding "Clear test data" deletes results and history; to remove settings too, clear this site's data in your browser.

Hitting public endpoints too hard could trigger a provider's rate limits or firewall (WAF) and spoil the result. So the test is kept far below that:

• One request at a time per host, with a 250–370 ms pause between samples (2–3 requests per second per host at most).
• At most 2 hosts per provider at once, and at most 8 hosts in total (4 by default).
• At most 21 requests per host per run (1 warm-up + up to 20). There's no continuous mode.
• A host is dropped after 3 failures in a row, not retried over and over.
• Requests are anonymous: no cookies, no referrer, no preflight. Answers are a few hundred bytes, HEAD is used where possible, and nothing large is downloaded.

A whole run uses less data than opening an ordinary web page. Every endpoint was checked to answer anonymous requests normally (a 200, 403 or 404 is fine for timing).

If your traffic goes through a proxy, the browser measures you-to-proxy plus proxy-to-provider, not your own line. The network panel looks for the usual signs: an exit network in a data center, a time zone that doesn't match the exit country, WARP, or a WebRTC exit that differs from the HTTPS one.

Use Get bypass rules to send just the test hosts direct (Clash / Mihomo, Surge, Shadowrocket, Quantumult X, Loon, sing-box, Xray, SwitchyOmega or a plain list), then check again. If it's the proxy you want to measure, leave it on: the numbers then show how the proxy really performs.

• Every row uses the same scale (logarithmic, 2 ms to 3 s). Dots are samples, the shaded box covers the middle half of them, and the line is the median.
• A narrow box means steady; a wide box or scattered dots mean jitter. A red × counts samples that timed out.
• Click a row to see each sample in order, all the stats and the endpoint used. ✓ marks a region that meets your limits.