Latency and Infrastructure for Automated Futures Trading: Co-location, DMA, and the Physics of Execution Speed

Overview #

Here's the honest version: most retail algorithmic traders spend way too much time worried about milliseconds when they should be worried about signal quality. But infrastructure does matter — just not in the way most people think, and not equally for all strategies.

Latency is the time between when your system sees a market event and when your order hits the exchange. That gap can be 80 milliseconds from a home internet connection, 5 milliseconds from a well-positioned VPS, or under 1 millisecond from a co-located server next to the CME matching engine in Aurora, Illinois. The question isn't just how big the gap is — it's whether your strategy actually cares.

A momentum strategy holding for 20 minutes doesn't care if your order got there 8ms or 12ms after the signal. A market-making strategy trying to get queue position before a price level gets hit absolutely does. Same concept, completely different infrastructure requirements.

This article breaks down the full picture: what latency actually consists of, how the infrastructure tiers compare, what real numbers to plan around, and most importantly — how to decide which tier is "enough" without burning money on co-location that won't move your P&L.

Key Concepts #

Tick-to-trade latency — The end-to-end time from when your system receives a market data update (the "tick") to when the exchange acknowledges your order (the "trade"). This is the number that actually matters. Every other latency metric is a subset of this.

Send-to-ack latency — The time from when your code calls the order submission function to when the exchange or broker confirms the order was received. Measures your order transmission speed specifically.

Tick-to-fill latency — Extends tick-to-trade by including the time until you receive an execution report confirming your fill. Longer than tick-to-trade because matching engine and report dissemination add time after acknowledgment.

{{IMAGE:latency-jitter-comparison-674cd83c.svg}}

Jitter — Variance in latency. A system that averages 5ms but swings between 2ms and 40ms has terrible jitter. Jitter is often more damaging than high average latency because it makes execution unpredictable. Plan around p95/p99, not averages.

Co-location (co-lo) — Physically placing your servers in or immediately adjacent to the exchange's data center ecosystem. For CME Globex, that means Aurora, Illinois, specifically near the CME's matching engine infrastructure.

Proximity hosting — A step below true co-lo. Your servers are in a data center near the exchange (often Chicago metro), connected to the exchange via dedicated low-latency paths. Not inside the exchange ecosystem but materially better than generic cloud hosting.

Direct Market Access (DMA) — Orders reach the exchange through a path with minimal middleware. True DMA means fewer broker systems, fewer hops, and lower latency. In practice, "DMA" is marketing shorthand that brokers use loosely — always verify what's actually in the path.

{{IMAGE:latency-queue-position-dom-674cd83c.svg}}

Order queue position — At a given price level, orders are filled in priority order (usually price-time priority). If you're tenth in queue at a price and only nine contracts trade there, you don't get filled. Co-location matters partly because being faster gets you better queue position before a price level gets swept.

Tick-to-trade budget — The maximum end-to-end latency your strategy can tolerate before execution performance degrades measurably. A strategy that uses signals decaying over 30 seconds has a budget measured in seconds. A market-making algo has a budget measured in microseconds.

{{IMAGE:latency-infrastructure-tiers-674cd83c.svg}}

The Latency Stack: What You're Actually Measuring #

Latency isn't one number. It's the sum of every component in the chain from exchange to you and back.

Here's what @Fat Tails mapped out in a widely-cited NexusFi post on measuring latency:

That's five steps before your order gets accepted. Each one adds latency. Miss-optimizing step 2 (data feed) while running a slow broker at step 5 is like putting racing tires on a truck. You need all the components to match.

The real components:

1. Exchange → data feed provider — CME multicast feeds are disseminated from Aurora. If you're using a data feed (IQFeed, Rithmic, CQG), the feed provider's servers receive this first, then retransmit to you.

2. Data feed → your system — The transmission from the provider's servers to wherever your code runs. This is where geographic distance kills retail traders on home internet. A server in Aurora talking to a server in Chicago adds microseconds. A server in Aurora talking to a PC in Florida adds 25-40ms of pure propagation delay.

3. Your strategy code processes the event — Computation time. Usually microseconds for simple strategies, but can balloon with inefficient code (database calls, memory allocations in hot loops, blocking I/O).

4. Your system → broker gateway — Order transmission to your broker. This reverses the data path. If your VPS is 15ms from the broker's gateway, add 15ms here.

5. Broker gateway processes the order — Pre-trade risk checks, FIX message handling, session management, rate limit enforcement. Can add 1-10ms depending on broker technology.

6. Broker → exchange gateway ingress — The last mile from broker to exchange. If your broker is co-located or has dedicated exchange connectivity, this is sub-millisecond. If they're routing through public internet, add variable latency.

Total tick-to-ack: Add it all up. From a home connection on the East Coast hitting CME, you're looking at 40-80ms on a good day, spiking badly during market stress when everyone else is also sending orders.

{{IMAGE:latency-tick-to-trade-stack-674cd83c.svg}}

Infrastructure Tiers: From Kitchen Table to Aurora #

Five tiers, five very different realities.

Tier 1: Home internet Cost: $0 extra (you're already paying for internet) Latency: 20-100ms+, high jitter Reality: Fine for strategy prototyping and backtesting. Running production automated strategies here means your execution is at the mercy of your ISP, your router, and your neighbors running Netflix at 3pm. Latency spikes during market volatility exactly when you need reliability most.

Tier 2: Generic cloud VPS (AWS/Azure/random region) Cost: $20-100/month Latency: 10-40ms depending on region selection Reality: Better than home internet. 24/7 uptime without your computer crashing. But a generic AWS us-east-1 VPS talking to CME in Aurora is still adding significant distance. AWS Chicago (us-east-2) is materially better. Worth it just for uptime and consistency, not for latency optimization.

Tier 3: Trading-focused VPS near broker infrastructure Cost: $50-200/month Latency: 2-15ms Reality: This is where most serious retail algo traders end up and where the cost-benefit genuinely makes sense. Providers like Speedytradingservers (IL-based, near CQG infrastructure) have been mentioned repeatedly in NexusFi discussions. @planetkill ran 1-2ms ping to CQG at 64.208.x.x from a trading-focused provider:

For strategies with holding periods from seconds to hours, this tier handles 95%+ of retail automated trading needs.

Tier 4: Proximity hosting (exchange-adjacent data center) Cost: $500-2,000+/month Latency: 0.5-5ms typical Reality: Your servers in the same data center ecosystem as the exchange gateway — usually Equinix CH2 or CH4 in Chicago/Aurora area. @hyperscalper documented achieving roughly 20-30ms when not co-located vs materially lower with proper setup:

The jump from Tier 3 to Tier 4 is expensive. Justify it only if your strategy is demonstrably sensitive to that latency band.

Tier 5: True co-location + DMA Cost: $5,000-50,000+/month Latency: sub-ms to 3ms Reality: You're physically in the same data center as the CME matching engine. Direct cross-connects. Your servers on exchange-grade hardware. This is what serious HFT shops run. As @Nicolas11 explained in the Elite Circle HFT thread:

49 microseconds per 10km of fiber. That's why location matters at the HFT level. For everything else, it's irrelevant.

{{IMAGE:latency-vps-stability-674cd83c.svg}}

Realistic Latency Numbers: Plan Around These #

Stop optimizing for averages. Plan for your 95th and 99th percentile latencies — those are the numbers that actually determine when your orders arrive during the market conditions that matter most.

These are planning ranges. Your actual numbers depend on: the specific broker gateway you're connecting to, your code efficiency, your OS/network configuration, and market conditions. Under high-volatility conditions with thousands of strategies all slamming the exchange simultaneously, latency spikes — often by 2-5x — in every tier.

@iantg measured this directly using Rithmic's API:

Market volatility directly affects latency. Plan your strategies around worst-case, not best-case.

{{IMAGE:latency-dma-gateway-components-674cd83c.svg}}

DMA and Broker Gateways: Where Speed Actually Disappears #

DMA sounds great in broker marketing. In practice, the speed of your "DMA" path depends entirely on what the broker actually built. And brokers vary enormously.

The components inside a broker gateway that eat latency:

Pre-trade risk checks — Every order gets validated before it touches the exchange. Margin available? Contract size within limits? Account in good standing? Simple checks take 0.5-2ms. Complex real-time portfolio checks can take 5-10ms.

FIX message serialization — Converting your native API call to FIX protocol format. Usually fast but adds overhead.

Session throttling — CME limits message rates. Brokers enforce these limits and may queue orders during burst periods. Your 2ms message gets queued behind 50 other messages = 60ms actual delivery.

Internal order management system — Large retail brokers route through multi-tier order management systems. Each hop adds latency.

@SMCJB put the DMA picture in perspective in the context of TT (Trading Technologies) vs fully co-located approaches:

Key insight: even TT's algo engines, which are physically co-located at Aurora, add overhead because they're routing through TT's infrastructure before hitting the exchange. There's always a stack between you and the matching engine. The question is how thin that stack is.

Asking the right questions before choosing a broker for algo trading:

1. Where is your gateway server physically located?
2. What is your typical send-to-ack time for ES market orders?
3. What are my order and cancel rate limits per second?
4. Is there any queueing in your gateway during high-volume periods?
5. Are market data and order routing on the same network path?
6. What happens to my open orders during a gateway disconnection?

If a broker can't answer questions 1 and 2 with specific numbers, their "DMA" claims are marketing.

{{IMAGE:latency-fiber-microwave-674cd83c.svg}}

Fiber vs Microwave: What Retail Traders Actually Need to Know #

The fiber vs microwave debate matters in one very specific context: ultra-long-haul connections between major financial centers where HFT firms compete for propagation delay advantage. Chicago to New York, or Chicago to London.

Light travels through fiber at roughly 200km/millisecond. That's about 200km for 1ms of one-way propagation delay. The 1,200km between Chicago and New York adds about 6ms in propagation delay alone. Microwave (which travels through air rather than fiber) moves at close to the speed of light in vacuum — about 300km/millisecond. So microwave cuts that propagation delay much.

For HFT firms running arbitrage between CME and CBOE or CME and ICE, shaving 1-2ms on the Chicago-New York route is worth millions per year. Hence the network of microwave towers HFT firms have built across the Midwest.

For everyone else: completely irrelevant. If you're running a retail algo strategy on CME Globex products, the distances involved (your server in Chicago/Aurora connecting to the exchange also in Chicago/Aurora) are measured in kilometers, not thousands of kilometers. Propagation delay across a data center is microseconds. Microwave vs fiber is not a variable you control or benefit from at retail scale.

What matters at your scale: the quality of the fiber between your server and the exchange gateway. A direct fiber cross-connect inside an exchange data center adds nanoseconds. A path that hops across the public internet adds variable jitter. That's the relevant comparison — not fiber vs microwave.

{{IMAGE:latency-timestamp-measurement-674cd83c.svg}}

Measuring Your Own Pipeline: The 5-Point Timestamp Stack #

You can't improve what you haven't measured. Most retail traders running automated strategies have no idea what their actual tick-to-trade latency is — they assume, and assumption here is expensive.

The measurement stack:

Point 1: Data receipt timestamp — When your code receives a tick event from the market data feed. Many feeds provide a "feed timestamp" embedded in the message (the time the feed server received the data from the exchange). Compare this to your local timestamp to measure feed delivery latency.

Point 2: Strategy decision timestamp — When your code decides to place an order. Usually measured from a System.currentTimeMillis() or equivalent call at the decision point in your strategy logic.

Point 3: Order send timestamp — When your code calls the broker API's order submission method. Measuring from Point 2 to Point 3 gives you your internal computation latency.

Point 4: Order acknowledgment timestamp — When the broker/exchange callback fires confirming your order was accepted. The delta from Point 3 to Point 4 is your "send-to-ack" — the number that most directly reflects your infrastructure quality.

Point 5: Fill timestamp — When your execution report arrives. Delta from Point 3 to Point 5 includes matching engine processing and report dissemination.

@Fat Tails laid out the CME direct path analysis with the implications for where each latency component lives:

That "bypassing the authorization process" is the core of what makes HFT infrastructure different from retail DMA. Sponsored access means your orders skip the broker's pre-trade risk stack entirely. For retail, every order goes through that stack.

Compute distributions, not averages:

Total samples: 1000 orders
P50 (median): 4.2ms
P95: 12.1ms
P99: 28.7ms
Max observed: 147ms (occurred during FOMC announcement)

That max of 147ms during FOMC is the number that burns you on a momentum strategy. If your signal says "buy on breakout" and your order arrives 147ms after the breakout happened, you bought into the move instead of at the start of it.

{{IMAGE:latency-strategy-sensitivity-674cd83c.svg}}

When Latency Matters vs When Strategy Wins #

The heuristic that actually works: if your strategy's expected value doesn't change when you add 10-20ms of artificial latency in backtesting, infrastructure upgrades won't help.

Strategies where infrastructure matters: #

Market making — You're posting bids and offers and trying to collect spread. If the market moves 1 tick before your cancel arrives, you've been "picked off" — sold at the old price when buyers already knew the price was going higher. Queue position and cancel speed are core to P&L. Every millisecond you save on order updates reduces adverse selection.

Statistical arbitrage (spread trading) — You're buying ES while selling NQ when the spread diverges from historical norms. If you're slow, someone else closes the spread before your orders get there. Speed determines whether you capture the edge or just pay commissions on incomplete hedges.

Scalping on microstructure signals — Using order flow imbalance, DOM pressure, or tick data signals with edge lives that last 100-500ms. If your whole signal edge is in that window and your execution takes 50ms, you've consumed 10-50% of your available reaction time before you've placed an order.

Strategies where strategy quality matters more: #

Trend following (minutes to hours) — A 10ms execution difference is noise compared to the 30-second moves trend signals capture. You need good signal generation, proper sizing, and exits that don't get you stopped out on normal volatility. Infrastructure plays zero role here.

Mean reversion strategies — Entry timing at the millisecond level is irrelevant when your entry criterion is "price is 2 ATRs below 20-period mean." The signal is slow, the edge is statistical. Get execution right at the second scale, not the millisecond scale.

Overnight gap strategies — You're entering before the close or after the open. Millisecond execution is irrelevant.

The practical test: run your backtest with execution delayed by 50ms at every order. If your P&L drops materially, your strategy has latency sensitivity. If it's basically unchanged, you're spending mental energy on the wrong problem.

@hyperscalper, who has run automated strategies for years including work toward co-location, put it directly:

This is someone who understands the infrastructure environment well and has consciously chosen to focus resources on analysis over raw speed. That's the right call for most non-HFT strategies.

{{IMAGE:latency-ninjatrader-path-674cd83c.svg}}

Practical Implementation: The NinjaTrader/Rithmic/CQG Reality #

Most retail automated futures traders are running one of three stacks: NinjaTrader via CQG/Rithmic/NTBrokerage, Sierra Chart with its own data connection, or a custom API build using Rithmic directly.

NinjaTrader platform-based strategies: NinjaTrader itself adds overhead on top of whatever broker connection you're using. The platform handles order management, risk checks, and event routing. @hyperscalper measured CQG-connected execution via NinjaTrader:

Under 10ms fill-to-order via CQG from a well-positioned server. That's a reasonable benchmark for what's achievable with NinjaTrader strategies on a proper VPS.

Rithmic API (direct): Rithmic's R|API+ allows direct low-latency connection, bypassing NinjaTrader's overhead. @iantg built a custom system specifically for lower latency:

The explicit mention "needs to be faster than NinjaTrader" confirms the platform overhead is real and measurable. If sub-10ms matters for your strategy, the Rithmic API route eliminates a significant overhead layer.

@LukePoga measured Rithmic tick delays directly and found something important:

Key finding: 350-microsecond ping to the data center, but 3-4ms tick delay. The latency wasn't the network — it was inside Rithmic's feed infrastructure. This is why measuring the full stack matters. Optimizing your network when the bottleneck is the data provider is wasted effort.

CQG infrastructure: CQG has exchange co-location at multiple venues including CME. Their servers in Aurora add minimal latency to both market data and order routing. @SMCJB's co-location discussion illustrated what's achievable when execution software is already co-located:

The implication: CQG and TT (both exchange-adjacent for their server infrastructure) are already near the top of what retail-accessible infrastructure delivers. The remaining latency is broker gateway processing, not network distance.

{{IMAGE:latency-failure-modes-674cd83c.svg}}

Infrastructure Failure Modes That Kill Automated Strategies #

Most automated strategy blowups aren't caused by bad signals or bad infrastructure — they're caused by failure modes in the integration between them.

Stale book states on order placement — Your strategy fires on a DOM snapshot that arrived 8ms ago. By the time your order hits the exchange, the price level has moved. You're chasing a price that no longer exists. Fix: always check current price against your signal trigger before submitting, with a threshold.

Reconnection gaps causing missed events — Your broker connection drops for 2 seconds during a volatile period. You reconnect but miss 12 order fills and 3 cancels. Your position tracking is now wrong. Orders you think are open have been filled. Fix: full position reconciliation on every reconnect, always.

Rate limit exhaustion during high-volatility periods — Your strategy is canceling and replacing orders as the market moves. Works fine in normal markets. During a volatile session, it places 200 cancel-replaces in 3 seconds, hits the CME 50-message/second limit, and your orders get queued or rejected. Fix: throttle your own cancel-replace rate and track outstanding messages.

Data feed vs order routing path divergence — Your data feed shows one price. Your broker's order routing is seeing a different price from a different data source. Your spread strategy fires based on a spread that doesn't actually exist in the execution path. Fix: use the same underlying data source for signals and execution validation.

Gateway timeout without disconnect notification — Your broker connection goes silent. Not a clean disconnect — just goes quiet. Your strategy assumes it's still connected and keeps running. It's not. Orders aren't being sent. Fix: heartbeat monitoring with automatic disconnect detection and reconnect logic.

@Fat Tails described the co-location decision framework around exactly these operational considerations:

A limit order sitting on the book gets filled when price reaches it — latency doesn't matter for that fill. Latency matters for: getting the order onto the book before the price reaches it, canceling the order before an adverse price movement sweeps through it, and replacing it at a new price quickly enough to maintain queue position. Know which of these your strategy actually depends on.

{{IMAGE:latency-decision-framework-674cd83c.svg}}

The Latency Budget Decision Framework #

A practical decision tree for deciding what infrastructure you actually need:

Step 1: What is your strategy's typical holding period?

• Less than 5 seconds: Latency matters much, continue to Step 2
• 5 seconds to 5 minutes: Latency matters at the edges, Tier 3 VPS is likely sufficient
• More than 5 minutes: Latency doesn't matter, any Tier 2+ setup works

Step 2: Run the 50ms delay test Add an artificial 50ms sleep before every order submission in your backtesting or simulation environment. If P&L drops by more than 10%, your strategy has real latency sensitivity.

Step 3: Measure your current actual latency Instrument tick-to-ack as described in the measurement section above. Run 1,000+ samples across different market conditions. If you're consistently above your Step 1 requirement, you have an infrastructure gap to close.

Step 4: Identify the actual bottleneck Run the timestamp analysis. Is most latency in:

• Data feed delivery? → Upgrade data feed provider or get closer to their servers
• Your code processing? → Improve computation, eliminate memory allocations in hot paths
• Order transmission? → Upgrade network, move server closer to broker
• Broker gateway? → Switch brokers or upgrade to DMA

{{IMAGE:latency-infrastructure-roi-674cd83c.svg}}

Step 5: Apply cost-benefit math Co-location at $5,000/month only makes sense if it's expected to add more than $5,000/month to P&L. A strategy trading 5 times per day with $100 average edge doesn't justify co-lo. A strategy trading 1,000 times per day where latency saves $0.10 per trade adds $100/day = $2,500/month. Now the math works.

For most retail automated traders, this framework lands at Tier 3: a dedicated trading VPS near Chicago with low-jitter connectivity to their broker. That handles the vast majority of what retail algorithmic strategies actually need.

{{IMAGE:latency-colocation-geography-674cd83c.svg}}

Quick Reference: Infrastructure Checklist for Automated Futures Traders #

{{IMAGE:latency-signal-decay-budget-674cd83c.svg}}

Baseline requirements (all automated traders):

• [ ] 24/7 uptime via VPS or dedicated server (no desktop/laptop)
• [ ] Located near your broker's primary gateway (Illinois for CME strategies)
• [ ] Stable, low-jitter connection — dedicated server beats shared VPS for consistency
• [ ] Heartbeat monitoring with automated reconnect logic
• [ ] Full position reconciliation on every reconnect
• [ ] Kill switch that can halt all orders independently of your main strategy process

For latency-sensitive strategies (sub-1 minute signals):

• [ ] Tick-to-ack measurement implemented — know your actual p50/p95/p99
• [ ] 50ms delay backtest completed — confirmed strategy has latency sensitivity before investing
• [ ] Rate limit tracking — know your broker's limits and your strategy's consumption
• [ ] Error handling for every order state: partial fills, rejects, late cancels, out-of-order reports
• [ ] Data source and order routing path verified to use same price reference

For proximity/co-location consideration:

• [ ] Tier 3 infrastructure deployed and measured
• [ ] Strategy P&L demonstrates clear latency sensitivity (>10% degradation in 50ms test)
• [ ] Monthly co-location cost justified by expected monthly P&L improvement
• [ ] Operations team (or yourself) prepared to monitor and maintain co-lo setup