Latency Coordinates & Fiber Model Inputs
How AS203314 resolves public city-centre coordinates with GeoNames and selects fiber, attenuation, amplifier, and route-stretch model inputs.
The latency model starts with public city-centre coordinates, then applies the physical constants and engineering assumptions listed below. The formula verification works through the equations and a fixed numerical example.
A city reference, not a facility address
Published coordinates identify the GeoNames city centre. They deliberately do not reveal a router, carrier hotel, cable landing station, or other private infrastructure location. The resulting value is a city-to-city physical reference, not a reconstruction of the production fiber route.
1. Resolving the theoretical physical location
Coordinate lookup uses the PoP's public city name and ISO 3166-1 alpha-2 country code. The GeoNames Search Webservice receives these constraints:
| Parameter | Value | Purpose |
|---|---|---|
name_equals | Public PoP city name | Prefer an exact toponym or alternate-name match |
country | ISO country code | Prevent collisions such as Paris, France vs. Paris, Texas |
featureClass | P | Restrict results to populated places |
style | FULL | Return identity and location fields needed for validation |
maxRows | 20 | Permit local disambiguation when names are shared |
When the exact query returns no result, the resolver retries with a required-name search. It normalizes diacritics, checks the country and populated-place class, then selects the highest-population exact or alternate-name match. This resolves names such as São Paulo, Frankfurt am Main and New York City without a facility address.
The checked snapshot records the GeoNames ID, canonical name, feature code, coordinates, source, date and attribution. Refresh it with pnpm --filter @hatsnet/docs geonames:refresh and GEONAMES_USERNAME. Normal builds read the snapshot rather than querying GeoNames.
| PoP | GeoNames place | Country | City-centre coordinates |
|---|---|---|---|
| AMS | Amsterdam | NL | 52.37403, 4.88969 |
| BER | Berlin | DE | 52.52437, 13.41053 |
| FRA | Frankfurt am Main | DE | 50.11552, 8.68417 |
| LON | London | GB | 51.50853, -0.12574 |
| MRS | Marseille | FR | 43.29695, 5.38107 |
| MOW | Moscow | RU | 55.75204, 37.61781 |
| PAR | Paris | FR | 48.85341, 2.34880 |
| IAD | Ashburn | US | 39.04372, -77.48749 |
| LAX | Los Angeles | US | 34.05223, -118.24368 |
| MIA | Miami | US | 25.77427, -80.19366 |
| NYC | New York City | US | 40.71427, -74.00597 |
| SEA | Seattle | US | 47.60621, -122.33207 |
| GRU | São Paulo | BR | -23.54750, -46.63611 |
| HKG | Hong Kong | HK | 22.27832, 114.17469 |
| MEL | Melbourne | AU | -37.81400, 144.96332 |
| SIN | Singapore | SG | 1.28967, 103.85007 |
| SYD | Sydney | AU | -33.86785, 151.20732 |
| TPE | Taipei | TW | 25.05306, 121.52639 |
| TYO | Tokyo | JP | 35.68950, 139.69171 |
| JNB | Johannesburg | ZA | -26.20227, 28.04363 |
The coordinate snapshot uses GeoNames data under CC BY 4.0. It is separate from operational topology records.
2. Model inputs and engineering evidence
Constants, material properties and engineering assumptions have different evidential roles:
| Input | Model value | Role and evidence |
|---|---|---|
| Earth model | WGS-84 ellipsoid | The inverse geodesic uses Charles F. F. Karney's robust Algorithms for geodesics |
| Vacuum light speed | 299,792.458km/s | Exact physical constant used for the absolute propagation floor |
| Standard fiber group index | 1.4679 | Conventional single-mode reference from Corning's fiber latency white paper |
| Low-latency group index | 1.4620 | Optimistic SMF-28 ULL material comparison from the same Corning paper |
| Optical path allowance | 1.05× | Transparent engineering reference for slack and small route deviations |
| Attenuation reference | 0.20dB/km | Conservative long-haul single-mode planning value |
| Optical span | 80km | Lower edge of the 80–120km range in Cisco's long-haul design guide |
| Amplifier transit delay | 0.05µs per pass | Rounded from the roughly 10m equivalent fiber length described by the GÉANT transport report |
| Mapped-fiber reference | 1.33× | Median conduit-to-geodesic comparison reported in Dissecting Latency in the Internet's Fiber Infrastructure |
ITU-T G.652 defines the relevant characteristics of standard single-mode fiber. The broader distinction between the speed-of-light baseline and routed-network path inflation is also discussed in cISP: A Speed-of-Light Internet Service Provider.
Formula derivation and numerical verification
See Theoretical Fiber Latency Formula Verification for the rendered equations, unit conversions, boundary checks, and the complete Tokyo (TYO) to Sydney (SYD) worked example.
3. Separation of model layers
- The geographic layer resolves city-centre coordinates and the shortest WGS-84 surface distance.
- The physical layer compares vacuum, conventional silica, and low-latency silica propagation.
- The engineering layer adds a 5% path allowance and idealized inline-amplifier transit time.
- The research layer provides a 1.33× mapped-fiber comparison without treating it as a universal route prediction.
- The comparison layer relates the published RTT to the standard-fiber physical floor.
Attenuation affects optical power, span count and amplifier count, not the speed of propagation. This lower-bound model excludes vendor-specific transponder, FEC, OTN switching, router, serialization and queueing delays.
4. Estimated stability indicators
City-pair pages report statistics from their published probe round. The separate 24-hour, 7-day and 30-day trend graphic is an estimated comparison, not a history of collected rounds. City-table jitter and loss fields are also estimated indicators.
Do not use estimated indicators as an outage record or an SLA measurement.
5. Interpretation checklist
- Use vacuum RTT only as an absolute law-of-physics reference.
- Use fiber RTT as the shortest possible RTT through standard silica along the WGS-84 geodesic.
- Use engineering floor as a transparent low-latency optical design reference with small cable and amplifier allowances.
- Use 1.33× mapped-fiber RTT as a research comparison, not as a universal route prediction.
- Compare efficiency across routes only after considering city-centre coordinates, submarine cable geography, routing policy, and normal measurement variation.
- Do not interpret any value on these pages as an SLA or as disclosure of a production facility or cable path.
The formula verification shows the calculation. Published observations are in the latency matrix and the city-pair directory.
Global Ping & RTT Latency Matrix | AS203314
Compare ping, RTT, physical fiber limits, jitter and packet loss across 20 Hats Network (AS203314) global backbone PoPs, updated daily.
Theoretical Fiber Latency Formula Verification
Verify AS203314's theoretical fiber latency model with rendered equations, unit checks, and a complete Tokyo-to-Sydney numerical reconciliation.