Stratum Latency Measurement Methodology

The Challenge: Browser Restrictions

Modern web browsers are built with a "Shared-Nothing" security model. For safety, code running in the browser (JavaScript) is strictly forbidden from opening raw TCP sockets. This creates a problem: how do you measure latency to a Stratum pool that communicates over TCP (usually on port 3333)?

The Solution: Cross-Origin Timing

While we cannot speak the Stratum protocol, we can still "knock on the door." The Stratum Pool Pinger uses the fetch() API to initiate an HTTP request to the Stratum endpoint.

Since the Stratum server isn't an HTTP server, it will eventually reject the connection or close the socket. However, the time it takes for the browser to reach the Connection Refused or Timeout state is highly correlated with the physical network distance.

Error Recognition

Our algorithm differentiates between different types of failure:

• TCP Handshake Success/Failure: Even if the protocol fails, the initial SYN/ACK handshake reveals the RTT.
• Protocol Mismatch: The time it takes for the server to say "I don't speak HTTP" is a valid latency measurement.
• Invalid Threshold: Latency below 9ms is often a local system rejection, which we flag as "Invalid."

Smoothing and Accuracy

Network jitter can skew individual measurements. To ensure professional-grade data, we use an Exponential Weighted Moving Average (EWMA):

NewAvg = OldAvg * (1 - α) + NewSample * α

This allows the tool to remain responsive to real network shifts while ignoring random spikes from local Wi-Fi noise or ISP congestion.

Browser vs. CLI Tooling

It is important to understand that this tool measures network proximity. It does not validate the pool's mining logic. For a complete test, including mining.subscribe and mining.authorize validation, we recommend using our CLI tool: dumb-stratum-proxy.