Broker latency: how to measure it and when it kills a scalper

Most people confuse network ping with total execution latency, but they aren't the same thing. A simple ping to your broker's server only measures the round-trip time for a network packet to travel from your machine to their gateway. It ignores the time their internal matching engine takes to process your order, validate your margin, and broadcast the fill back to you.

To get a real number, you need to measure the delta between sending an order request and receiving the acknowledgement message. You can log the timestamp when your script initiates the API call and compare it against the timestamp of the execution report. If you are using Python, use high-resolution timers like time.perf_counter() to avoid clock drift issues.

Here is a rough breakdown of how latency impacts your strategy:

• Under 10ms: High-frequency scalping is viable.
• 10ms to 50ms: You can scalp, but you will suffer from slippage on volatile moves.
• Over 100ms: Most short-term mean reversion or momentum scalping will likely be net negative due to adverse selection.

When your latency is high, you are essentially trading against the 'stale' prices of the previous millisecond. By the time your order reaches the book, the liquidity you saw is often gone or the spread has widened. You can test your specific environment using tools like QuantConnect to simulate how different execution delays eat into your theoretical alpha.

Remember that local network jitter is just as dangerous as high average latency. Even if your average is 20ms, spikes to 200ms during market open will kill your fill rates. Have you actually benchmarked your own broker's execution loop, or are you just relying on the ping time from your terminal?