# Latency Coordinates & Fiber Model Inputs This document defines the geographic inputs, physical constants, engineering assumptions, and evidence boundaries used by the Hats Network latency model. The complete equation derivation and numerical reconciliation are maintained separately on the [theoretical latency formula verification page](/docs/network/latency/theoretical-latency-verification). > **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 Each PoP already has a public city name and ISO 3166-1 alpha-2 country code. Our coordinate refresh process sends those two values to the [GeoNames Search Webservice](https://www.geonames.org/export/geonames-search.html) with the following 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 | If an exact query returns no result, the resolver retries a required-name search. It then normalizes diacritics, verifies the country and populated-place class, and chooses the highest-population exact name or alternate-name match. This handles examples such as **São Paulo**, **Frankfurt → Frankfurt am Main**, and **New York → New York City** without using a private datacenter address. The resolved snapshot stores the GeoNames identifier, canonical place name, feature code, latitude, longitude, source, date, and attribution. It can be refreshed with `pnpm --filter @hatsnet/docs geonames:refresh` when `GEONAMES_USERNAME` is available. Normal builds consume the checked snapshot, so an external rate limit cannot make latency pages non-reproducible. > Interactive content is available on the canonical HTML page. GeoNames data is published under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). The coordinate snapshot is a public geographic reference and is kept separate from operational topology data. ## 2. Model inputs and engineering evidence The model keeps measured constants, published material properties, and explicit engineering assumptions separate: | Input | Model value | Role and evidence | | -------------------------- | ---------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Earth model | WGS-84 ellipsoid | The inverse geodesic uses Charles F. F. Karney's robust [Algorithms for geodesics](https://doi.org/10.1007/s00190-012-0578-z) | | 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](https://www.corning.com/media/worldwide/coc/documents/Fiber/white-paper/WP8080_03-11.pdf) | | 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](https://www.cisco.com/c/en/us/td/docs/optical/ron/4-0/solution/guide/ron-solution-guide-40/deployment-topologies/r-long-haul-topology.html) | | Amplifier transit delay | 0.05µs per pass | Rounded from the roughly 10m equivalent fiber length described by the [GÉANT transport report](https://www.geant3.archive.geant.org/Media%20Library/GN3-13-109_DJ1-1-3_Transport-Network-Technologies-and-Operations.pdf) | | Mapped-fiber reference | 1.33× | Median conduit-to-geodesic comparison reported in [Dissecting Latency in the Internet's Fiber Infrastructure](https://arxiv.org/abs/1811.10737) | [ITU-T G.652](https://www.itu.int/rec/T-REC-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](https://www.usenix.org/conference/nsdi22/presentation/bhattacherjee). > **Formula derivation and numerical verification** > > See [Theoretical Fiber Latency Formula > Verification](/docs/network/latency/theoretical-latency-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 does not directly reduce propagation speed. It determines optical power loss and the resulting span and amplifier count. Vendor-specific transponder, FEC, OTN switching, router, serialization, and queueing delays remain outside the universal lower-bound model. ## 4. Estimated stability indicators Route pages also show estimated jitter, packet-loss, percentile, and 24-hour/7-day/30-day trend indicators. They follow the latency matrix publication cycle and provide a consistent basis for comparing relative route stability. These indicators are suitable for route comparison and planning context. They are not 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. For the complete calculation, open the [formula verification page](/docs/network/latency/theoretical-latency-verification). For current values, return to the [global backbone latency matrix](/docs/network/latency), browse [latency by PoP](/docs/network/latency), or compare individual [city-pair ping and RTT pages](/docs/network/latency/pairs). --- ## License and attribution - **Canonical source:** [View the human-readable HTML page](https://hatsnet.io/docs/network/latency/theoretical-fiber-latency). - **Original documentation:** © Hats Network Inc., licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). - **Full terms:** [Content and Data License](https://hatsnet.io/docs/legal/content-and-data-license) — includes attribution requirements, third-party material, trademarks, source code and other exclusions.