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.

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 with the following constraints:

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.

GeoNames data is published under CC 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:

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.

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. For current values, return to the global backbone latency matrix, browse latency by PoP, or compare individual city-pair ping and RTT pages.