Latency Is Not Execution Speed

A trader sees 0.4ms beside a broker connection and calls it execution speed. It is an understandable shortcut. It is also wrong.

That number may describe a network round trip between two specific endpoints. A fill has a longer route: the platform must process market data, evaluate the trade, build the order, send it to a broker or clearing gateway, pass risk controls, reach a venue, enter the matching process, find available liquidity, and report the result back.

Some of those stages happen quickly. Some vary by broker, market, order type, and market condition. They are still separate stages.

This distinction is not an argument against low latency. Short, stable routes matter. So does fast compute. The point is to understand what each one improves, then stop asking one attractive number to explain the entire trade.

The Platform Goes First

For an automated strategy, the order path begins before a packet touches the network.

A market-data event arrives. The platform updates its internal state. Bars, indicators, order-flow calculations, and strategy conditions may need to run. If the condition is met, the platform constructs an order and passes it to the connection adapter.

This is where CPU performance enters the execution conversation. NinjaTrader can call OnBarUpdate() on every incoming tick, every price change, or once per completed bar. Its own documentation notes that calculating on every tick can be CPU intensive.¹ Add several instruments, custom indicators, NinjaScripts, DOM updates, and background processes, and the time between incoming data and order submission may no longer be trivial.

Discretionary trading has a platform stage too. A click still moves through the interface, order-entry logic, local validation, and the broker adapter before it leaves the machine.

Call this platform processing time. A fast single-threaded CPU, available processing capacity, and a responsive operating environment can reduce it. A lower network ping cannot. The packet is still waiting for the platform to create it.

That is why a trader can have a short broker route and a sluggish workspace at the same time. The network is ready. The platform is busy.

Ping Measures One Leg

Windows ping sends an Internet Control Message Protocol (ICMP) echo request and reports the round-trip time for the reply.² It is useful for checking whether a target is reachable and how quickly that specific test travels there and back.

Three details matter.

First, the target matters. Pinging a broker website, data server, or public address does not prove that the production order gateway sits in the same place or follows the same route.

Second, ping measures a network round trip. It does not include strategy calculations that happened before transmission, internal broker work after arrival, exchange matching, or the return of a fill report.

Third, one result says little about consistency. Traders should care about the distribution: normal latency, variation during busy periods, packet loss, and route changes. A route that is usually short but occasionally wanders is a different operating environment from one that stays predictable.

So keep the ping number. Just label it correctly: network round-trip latency to the tested endpoint.

That wording is less exciting than “execution in 0.4ms.” It is also useful.

The Broker Has Work To Do

Once the order reaches a broker, futures commission merchant, or market-access gateway, it does not simply wave on the way through.

The exact sequence depends on the market and access arrangement, but the gateway may verify the session, account, product permissions, order fields, position or credit limits, duplicate-order controls, and other risk rules before routing the order onward.

These controls are not optional decoration. SEC Rule 15c3-5 requires broker-dealers with market access to use pre-trade controls intended to stop orders that breach credit or capital thresholds, appear erroneous, or violate applicable restrictions.³ CME Globex also provides pre-trade risk systems for limits, permissions, blocked order entry, duplicate-order prevention, and related controls.⁴

The presence of a check does not imply that the broker is slow. Modern gateways are built to perform this work quickly. It does mean broker processing is a separate interval, controlled by a system outside the trader’s VPS.

Broker architecture matters here. So do account configuration, connection type, routing policy, current gateway load, and the path from the broker to the venue. Two traders with the same VPS location can still take different downstream routes.

Infrastructure can get the order to the broker sooner. It cannot remove the broker from the order chain.

Accepted Is Not Filled

Trading platforms expose several order states because “sent” and “filled” are different events.

NinjaTrader distinguishes an order that is Submitted to the broker from one that is Accepted by the broker or exchange, Working in the exchange queue, PartFilled, and finally Filled.⁵ CME’s iLink testing documentation likewise treats a new-order acknowledgement, a partial-fill notice, and a fill notice as separate messages.⁶

This gives us three useful clocks:

1. Submit time: the platform handed off the order.
2. Acknowledgement time: the broker or venue accepted it.
3. Fill time: some or all of the order executed.

The interval between submit and acknowledgement can reveal platform, network, broker, and venue-entry behavior, depending on what the connection reports. The interval between acknowledgement and fill is a different question. It includes marketability, matching rules, queue position, and available opposing interest.

Calling both intervals “execution speed” hides the part that needs diagnosis. A trader trying to fix a slow acknowledgement has a different problem from a trader whose passive limit order was accepted immediately and sat behind several hundred contracts.

One needs better path evidence. The other needs a conversation with the order book.

The Queue Decides What Happens Next

When an accepted limit order reaches a central order book, its price and priority determine where it stands.

Nasdaq, for example, describes a price-time model in which displayed limit orders at the same price execute in the order received.⁷ CME products use defined matching algorithms that may include first-in, first-out or pro-rata allocation, depending on the contract. CME’s Market by Order feed exists partly to show individual orders and queue position with greater granularity.⁸

Low latency matters because arrival time can affect priority. A faster platform and shorter route may place an order, change, or cancellation request at the venue sooner than a slower path would.

But once the order is resting, the next fill depends on what reaches that price and how the venue allocates executions. If 500 contracts are ahead of a ten-lot order and only 200 trade at the level, a fine network result does not produce a fill.

The same applies when two traders submit at nearly the same moment. Small differences in platform processing, network transit, gateway handling, and venue arrival can affect ordering. The relevant measurement is arrival and acknowledgement behavior, not the ping to a convenient public host.

The queue is brutally literal. It does not read hosting copy.

A Fast Route Cannot Create Liquidity

Aggressive orders remove the waiting problem, but they introduce the available-price problem.

A market order seeks execution against the best available opposing interest. If there is not enough size at the first price, the order may continue into additional levels. Investor.gov notes that market orders are generally executed quickly, but the execution price is not guaranteed and may differ from the quote when liquidity is limited or prices are moving.⁹

Limit orders reverse the trade-off. They control the worst acceptable price, but execution is not guaranteed. A limit order can arrive quickly, receive an acknowledgement quickly, and remain unfilled because the market never trades enough volume at that price.

This is why fill quality cannot be inferred from infrastructure latency alone. Order type, size, spread, volatility, queue depth, market impact, and venue routing all matter. During a fast move, even a small timing difference can change the available book. That makes low latency valuable. It does not make the book stand still.

The honest proposition is narrower and stronger: reduce avoidable delay before the order reaches the systems that make the matching decision.

Measure The Path In Pieces

If execution matters enough to optimize, it matters enough to timestamp properly.

Start with the event that triggered the trade and record each state the platform or broker exposes. NinjaTrader’s order object includes state changes and a time for the latest change. FIX execution reports carry order status, execution type, filled quantity, remaining quantity, and average price fields.¹⁰

Interval	Start	End	What It Can Reveal
Platform decision	Market event received	Order submitted	Strategy, indicator, platform, and CPU delay
Submission path	Order submitted	Broker or venue acknowledgement	Adapter, network, gateway, and venue-entry delay
Working time	Acknowledged or working	Partial or full fill	Marketability, priority, queue, and liquidity
Report return	Venue event	Platform update received	Downstream reporting and return-path delay

The available timestamps depend on the platform and connection. A retail front end may expose less detail than a FIX session or institutional gateway. Clock synchronization also matters when comparing records created on different machines.

Do not force false precision where the data does not support it. If the platform records only local order-state times, say so. If the broker provides exchange timestamps, keep them separate from local receipt times.

The useful outcome is not the smallest number. It is knowing which interval changed when the trading experience changed.

Improve The Stages You Control

The execution chain contains both infrastructure variables and market variables.

You can improve platform processing with faster cores, enough memory, fast local storage, and processing capacity that remains available to the trading workload. You can improve network transit by placing the server near the broker or venue, using short routes, maintaining redundant paths, and watching latency consistency rather than one best result.

This is the part ChartVPS is built to handle. Ryzen 9 9950X processing reduces avoidable platform delay. Exchange-adjacent locations reduce geographic distance. Redundant network capacity and route diversity keep the path from depending on one carrier. From Chicago, typical ChartVPS network latency to CME is 0-1ms.

That figure describes the network leg. It does not promise a 0-1ms fill. Broker controls, venue processing, matching rules, queue position, liquidity, and the strategy itself still have their jobs to do.

Technical honesty does not weaken the case for better infrastructure. It makes the case precise.

A faster platform can reach a decision sooner. A shorter route can deliver the order sooner. A stable environment can make those intervals more consistent. That is a real edge, and it is enough without pretending the server controls the market.

Related Reading

• Why Single-Thread Performance Still Matters in Trading
• ChartVPS Data Centers
• Alpha CPU-Driven Trading VPS
• NinjaTrader VPS Infrastructure

Sources

1. NinjaTrader Help Guide, Calculate. ↩
2. Microsoft Learn, Ping. ↩
3. U.S. Securities and Exchange Commission, Risk Management Controls for Brokers or Dealers With Market Access. ↩
4. CME Group, Pre-Trade Risk Management. ↩
5. NinjaTrader Help Guide, Order. ↩
6. CME Group, Market Orders for Pre-Registered or On-Demand Format. ↩
7. Nasdaq Trader, The Nasdaq Stock Market. ↩
8. CME Group, Market by Order. ↩
9. Investor.gov, Understanding Order Types. ↩
10. FIX Trading Community, Execution Report. ↩