Keep latency and address country apart
Round-trip time is how long a packet takes to reach the machine and come back. Distance, submarine cables, the carrier’s exit, and that day’s congestion all sit in that number. Address country is what a registry and a geolocation database print on the IPv4. Fill both columns. One does not stand in for the other.
Every round-trip in this note is toward a machine deployed in Tokyo, Japan. A geolocation database will usually mark that address as Japan. A user in Shanghai still crosses the path from Shanghai to Tokyo. Marking the address as Japan does not shorten that path.
The reverse is the same. If users are already in Tokyo and the page is still slow, count round-trips inside the app before you add an IP. An extra address stays on the same machine. The path does not change. Where the operator sits is a separate row. Do not average it with visitors. A comfortable SSH session only says the operator is close enough. It says nothing about visitors.
Latency follows where users are and whether the path is congested. A Japan address follows whether anyone checks the country. If nobody checks, the included address is enough for login and for the site.
Budget round-trip time from where users are
Write the user as a city plus an access type: home broadband, mobile, or an office exit. Keep at least three samples. A company VPN and your own jump host are not the visitor path.
In fiber, about 200 km is 1 ms one way. Double that for a round trip, then add routing and queues. The table is that order of magnitude. It is not a carrier promise, and it is not a figure we guarantee after delivery. Once your mtr is in, retire the table.
| Users are mostly in | Budget band | Accept this before you measure |
|---|---|---|
| Japan, same metro as the machine | Often single digits to the mid-20s ms | Ordinary sites and APIs are usually tight enough. Games and quotes still need the worst tenth |
| Japan, another metro | About 10–40 ms | Still a domestic path. The international exit is usually not the cause |
| Seoul, Taipei | About 30–70 ms | One submarine hop. Record daytime and overnight separately |
| Hong Kong | About 50–80 ms | Users concentrated in Hong Kong are closer to Hong Kong. Users in Japan are closer to Tokyo |
| Major cities in mainland China | Tens of ms when the exit is clear; past 100 ms when it is not | The gap is the international exit, not the hop inside the city. Do not memorize one fixed number |
| Singapore, Bangkok, Manila | About 70–100 ms | If the audience is inside Southeast Asia, Tokyo is not their nearest point |
| US West Coast, Europe | West Coast about 100–150 ms; Europe about 200 ms and up | Fine for a few operators. A poor fit for a click-heavy site aimed at local users |
Set Hong Kong beside this path and compare distance, not a ranking. Users in Hong Kong or along the south China coast usually have a shorter round trip to Hong Kong than to Tokyo. Users inside Japan have a shorter round trip to Tokyo. Users spread across Seoul, Taipei, and Tokyo sit nearer Tokyo as a group. That is distance. Whether the path is healthy today still comes from a measurement on the user network.
CN2, which shows up in a lot of searches, is a product name for a premium international exit on the China Telecom side. It is not a city, and it is not the country of an address. The same machine, reached from different carriers, can differ by a wide margin. Whether a listing prints those letters does not replace one mtr from the network that serves the business.
The milliseconds decide whether a measurement is worth doing. After you measure, keep only your median and your worst tenth. Someone else’s screenshot, or “as low as a few milliseconds” on an ad, does not enter the budget.
Measure from the user side
Measure once at the business peak and once overnight. That separates “the path is long” from “the exit is congested”. For each sample keep three numbers: minimum, median, and the worst 5%. The median is ordinary feel. The worst tenth is whether users occasionally stall. The minimum alone writes the path down as its single best packet.
Carriers sometimes deprioritize ICMP, so ping is only a first look. Then time TCP: a handshake to port 443 or 22, or time-to-first-byte on the homepage. mtr shows the hop where delay starts to climb. A climb inside the user’s metro does not move much if you change the machine’s city. A climb at the international exit means the bottleneck is leaving the country. A climb on the last hops after the submarine segment is the part that belongs to the machine’s city.
ping -c 50 target
mtr -rwzbc 50 target
curl -o /dev/null -s -w 'ttfb:%{time_starttransfer} total:%{time_total}\n' https://target/Before you have a machine, measure a Tokyo target whose location you already know. After you have one, repeat the test from the same user network and compare medians. Do not hand visitors a number taken from a VPN exit.
Multiply by how many round trips the app makes. A page that calls six APIs in series feels about six round trips, plus time on the server. A database in another city pays one cross-city round trip per query. In that layout, put the app and the database in the same place before you argue about address country.
Those three lines are feel, and your measurement still overrides them. An ordinary site with a median inside 80 ms is usually usable; above that, cut serial requests first. Games and quotes want the median inside about 40 ms. A spike to 300 ms hurts more than the median. An operator can still type over SSH around 150 ms. That row is only the operator. A graphical remote desktop feels direct inside about 80 ms and sticky past 150 ms. Someone who lives in the graphical session needs to sit near the machine, or keep the GUI local and manage over SSH. Linux uses SSH. Windows Server uses RDP. Record them as two paths.
How to read the run
-
1
Write visitors down, operators on another row
City plus home broadband, mobile, or office exit. Keep three networks. Jump hosts and VPNs stay out of the visitor column.
-
2
One run at peak, one overnight
Record minimum, median, and worst 5%. If the two runs match, distance dominates. If the peak is clearly worse, an exit or a middle hop is congested.
-
3
Mark the hop where delay climbs
A climb inside the metro barely cares which city the machine is in. A climb at the international exit is an exit problem. A climb on the last hops belongs to the machine’s city.
-
4
Multiply by serial calls
Pages, APIs, and the database each have their own round-trip count. One request and a page that asks eight times are not the same budget.
When a Japan address is actually required
Ask one question: does a downstream system check that this IP is in Japan? If nothing checks the country, round-trip time and address country are unrelated.
Hand the real address to the other side when the check is real. A Japanese payment, age, or content rule that only allows addresses in Japan. A partner firewall whose allow-list is a Japan range: they need the assigned address, not a sentence about the city. Delivery into Japanese mailboxes, where the receiver’s reputation system looks at the sending country. A Japan search or map API that admits by country. In those cases, let them look up the included IPv4 first. Talk about a second address after that lookup passes.
Do not buy a “local address” for the cases below. Users are in Japan, but no service checks the country. The included address is already on the machine. SSH, RDP, and the site leave through it. What you actually want to shorten is round-trip time for users in mainland China or in Europe. A Japan address does not change their distance to the machine. A CDN sits in front, visitors hit a nearby node, and the origin country is invisible to them. You want the geolocation database to print China or Hong Kong. An address on a machine deployed in Tokyo will not become that result.
A geolocation vendor, a cloud provider’s country field, and the browser language can disagree. Have the partner look the address up in the database their production system uses. A web search for “IP location” is often a different data set.
Several addresses do not become several countries. Extra IPv4 addresses are sold one by one and still leave from the same machine. The country in the database usually stays the same. Add one when two sites need separate reputation, or when one customer needs a separate exit. How the count works is in adding addresses one by one. The rule here is narrower: address count is not a latency knob.
Bandwidth and extra addresses do not move round-trip time
Port speed is how much data you can push at once. It is not how long one small packet takes to come back. A page of a few dozen kilobytes that still feels stuck is a round-trip and a request-count problem. Bandwidth is the topic when the port is already full and downloads no longer speed up. The default is 250 Mbps, unmetered. Raise it to 1 Gbps or 2 Gbps when that port is full. After the raise, a 60 ms round trip is still 60 ms.
Large downloads are the other way around. If round-trip time is already low and throughput is not, look at whether the port is full and whether the far side rate-limits. Do not answer “how much latency” with a speed-test megabit figure. That number is throughput. Latency is the time for one round trip.
| What you see | Look at | Do not do first |
|---|---|---|
| One user waits on a page, the port is idle | Median, serial calls, the hop where delay climbs | Raise 250 Mbps to 1 Gbps |
| Many people download at once, the port is full | The bandwidth step, and that traffic is unmetered | Buy more IPs and expect them to feel faster |
| A partner says the address country is wrong | Give them the included address and their own database | Buy bandwidth instead of checking country |
| Only the operator finds RDP sticky | The operator’s round trip, separate from visitors | Reshape the public site to suit the operator’s hands |
Match the machine after both checks pass
When the median on three user networks sits inside the budget, and the partner confirms the address country, then see whether the machine can hold the CPU and the disks. The processor is one AMD EPYC 7543P, 32 cores / 64 threads, 2.8–3.7 GHz, for one tenant. Memory is DDR4-3200 ECC RDIMM: 128 GB at $465 a month, or 256 GB at $592. You cannot add modules later. If the working set does not fit in 128 GB, take 256 GB. Disks are 2 × 1 TB NVMe, no hardware RAID, each disk attached directly. Usable capacity is 2 TB, not the 1 TB left after a mirror. If you need more space, add up to two 2 TB disks at $83 a month each. Those stay direct-attached. They do not join a hardware array.
Linux reaches the included IPv4 over SSH. Windows Server Standard adds $21 a month, Datacenter adds $27, and access becomes RDP. The Windows language can be English, Traditional Chinese, or Simplified Chinese. Ubuntu 24.04 is the free default. Proxmox, Debian, AlmaLinux, and the other free images do not add a fee. Bandwidth steps are +$251 for 1 Gbps and +$749 for 2 Gbps, both unmetered. Each extra address is $2 a month, from 0 to 255 extra. With the included one, the server holds at most 256. Addresses are not sold as a subnet.
Monthly total is the chassis price, plus disk count times 83, plus the bandwidth step, plus extra addresses times 2, plus the OS add-on. The amount due is that monthly total times the number of months. Monthly, quarterly, half-year, and yearly terms all use that multiple. There is no discount and no setup fee. Use these numbers only after both measurements pass. Whether latency is enough, and whether you need an address in Japan, comes from your mtr and from the partner’s lookup. How the term multiplies is on the pricing page. Memory, disks, bandwidth, and address count change on the configure page.
Both checks passed. Pick the memory.
128 GB or 256 GB. Disks are 2×1 TB, direct-attached. One IPv4 is included. You can order before you sign in.