The Low-Latency Guide to Scalping: Every Millisecond in the Execution Chain Measured for 2026

The MetaTrader status bar says 0.5ms. The trade journal says 40ms. That is not a display error. The status bar measures network ping to the broker’s server. The journal measures the full round-trip: EA computation, terminal processing, network transit, broker bridge, liquidity provider fill, and confirmation return. Six components, each adding latency, only one of them controlled by the VPS. For scalpers spending money on infrastructure to shave milliseconds, knowing which milliseconds actually matter is the difference between a measurable execution improvement and an expensive placebo.

The research assembled in this guide points to a threshold that most VPS marketing does not advertise: below 20ms total network latency, spread and commission become the dominant execution costs, typically 10 to 100 times larger than latency-based slippage. The single largest improvement available to retail scalpers is moving from a home internet connection (50 to 300ms round-trip) to a VPS in the same city as the broker’s data center (1 to 10ms). Below that, each additional dollar spent on infrastructure buys progressively less execution quality. And the gap between the best retail VPS and institutional HFT, which operates 1,000 to 50,000 times faster, is unbridgeable by any hosting purchase.

This guide maps the full latency chain with measured data at each stage: end-to-end execution times from MQL5 forum measurements and broker reports, the honest threshold analysis, strategy-specific latency requirements (market-making, momentum, mean-reversion, news, grid), the HFT boundary, VPS configuration for minimum latency, and broker data center placement. Every VPS provider latency claim is flagged as commercially interested. The only published slippage-vs-latency experiment is critically assessed. Where data comes from a single source or a party with commercial interest, that is stated.

The article is written for scalpers evaluating whether their infrastructure is the bottleneck or their strategy is. If you are trading H4 or daily timeframes, latency is not your constraint and this guide is not for you.

The Six-Component Latency Chain

Every scalping trade passes through six distinct stages between the EA deciding to trade and the confirmation arriving back at the terminal. The total execution time is the sum of all six. Most traders measure only one of them.

Component A: EA computation. This is the time between OnTick() firing and the EA reaching its OrderSend() call. A well-optimized MQL5 EA with basic indicator checks completes this in under 1 millisecond. Complex EAs calling multiple indicators or performing several OrderSend() calls can extend processing to hundreds of milliseconds. One subtlety catches developers off guard: the first call to CopyBuffer() incurs approximately 100ms of initialization overhead, but subsequent calls drop below 0.1ms. For practical purposes, EA computation is negligible in the total chain for any reasonably written scalper. As MQL5 forum moderator William Roeder stated: the microseconds the EA takes are irrelevant compared to the 20 to 200 milliseconds the network takes.

There is a harder constraint. If OnTick() is still processing when a new tick arrives, MetaTrader discards the new tick. There is no queue. MetaQuotes documentation confirms this explicitly. Measured data from a multicurrency EA showed a 0.1 to 0.2% tick skip rate on non-native symbols, with skipped ticks correlating to processing delays averaging 103 to 118 milliseconds. MT4 processes a maximum of approximately 12 ticks per second per broker representative data. MT5 handles significantly more due to its multithreaded architecture, but the discard behavior on individual chart instances remains.

Component B: Terminal processing. The time between OrderSend() completing internally and the order packet leaving the terminal for the network. Sub-millisecond. The terminal packages the request and dispatches it almost instantly. This component is negligible. It exists in the chain for completeness, not because it requires optimization.

Component C: Network latency. This is the round-trip ping between the VPS and the broker’s server. It is the number displayed in MetaTrader’s status bar. It is also the only component in the chain that the VPS directly controls.

The ranges are well-documented. Cross-connected within the same Equinix facility: 0.3 to 1ms. Same city, different data center: 1 to 5ms. Same region (for example, Paris to London): 5 to 20ms. Transatlantic (New York to London): 60 to 90ms. Home internet to a local broker: 20 to 100ms. Home internet to a distant broker: 100 to 300ms.

Two trips through this component occur per trade: the order dispatch and the confirmation return (Component F). A 5ms ping adds 10ms total. A 100ms ping adds 200ms. This is why the home-to-VPS migration delivers the largest single improvement.

Component D: Broker bridge and gateway processing. This is where the broker’s infrastructure receives the order, applies risk checks, routes to a liquidity provider, and manages aggregation. The hardware is typically a bridge from PrimeXM (XCore), oneZero (Hub), Gold-i, or the new MetaQuotes Ultency engine. This component is invisible to the trader, uncontrollable from the VPS, and often the largest single contributor to total execution time.

MT4 broker-side processing runs approximately 50ms under normal conditions. MT5’s internal server processing is considerably faster at approximately 1 to 2ms, though total execution still includes LP response time on top of this figure. The distinction matters: a trader migrating from MT4 to MT5 may see a larger execution improvement from the platform change than from any VPS upgrade.

MetaQuotes Ultency, launched at the Finance Magnates London Summit in November 2025, is the most significant infrastructure development in this component. It is a native matching engine built into MetaTrader 5 that eliminates third-party bridge dependencies. BitDelta Pro measured 0.26ms latency after integration in December 2025. Pricing at $1 per $1 million traded (no fixed monthly fees) undercuts traditional bridge providers. Adopters include FxPro, LMAX Group, Vantage, and multiple LPs. The impact for retail scalpers: if their broker adopts Ultency, Component D shrinks from milliseconds to sub-millisecond without any change to the trader’s VPS.

Component E: Liquidity provider fill. The LP’s matching engine processes the order. This is variable, largely invisible, and depends on market depth, order size, and whether the LP applies “last look,” a window during which the LP reviews the order before confirming.

Last look hold times have compressed over recent years. CME’s EBS platform averaged 12ms in 2022. The industry average dropped to approximately 10ms by 2025. Cboe FX reduced its threshold from 35ms to 10ms in October 2025. LMAX Exchange operates with no last look at all, using strict price/time priority, achieving approximately 3ms average execution. Pre-trade risk checks can be performed in sub-microsecond time, meaning most of the hold window serves profitability assessment, not risk management.

For A-book (ECN/STP) brokers, this component is the LP’s domain. For B-book (market maker) brokers, the fill happens internally and can theoretically execute in under 1ms since no external routing occurs. However, some B-book brokers introduce artificial delays via “virtual dealer” plugins. OANDA’s 12ms average demonstrates the speed advantage of internal matching without artificial delays.

Component F: Confirmation return trip. Identical to Component C. The fill confirmation travels back from the broker’s server to the VPS over the same network path. This adds another copy of the network latency to the total.

A critical real-world measurement from an MQL5 forum user ties the chain together: “Execution time according to my ECN broker (to aggregator and back) = 16 to 20ms. From home super PC = 141ms (minus 110ms latency = 31ms execution). VPS minimum execution stable at 45 to 61ms.” The broker’s own processing consumed 16 to 20ms regardless of how the order arrived. The VPS reduced the network component. It did not reduce the broker component. That 16 to 20ms floor exists no matter what infrastructure the trader buys.

Measured End-to-End Execution Times

The six-component chain produces measurable totals. These figures come from MQL5 forum reports, ForexFactory threads, and broker data. None are laboratory-controlled experiments. They are real trades on real accounts, reported by traders with varying setups, brokers, and market conditions. That makes them noisy but representative of what scalpers actually experience.

The best documented case: an MT5 setup on a colocated VPS with 0.5ms ping to IC Markets at Equinix NY, measuring approximately 40ms total execution. That 40ms includes broker bridge processing, LP fill, and confirmation return on top of the sub-millisecond network transit. The trader’s VPS was as close to the broker as physically possible. The remaining 39.5ms belonged to components the VPS could not touch.

A good case on MT5 with a quality VPS running 1 to 10ms ping lands at 60 to 200ms total. This is the range most forex VPS marketing targets, and it is achievable with a same-city or same-data-center placement at $15 to $60 per month. The variation within this range depends primarily on broker bridge speed and LP response, not on whether the VPS ping is 2ms or 8ms.

MT4 on a VPS typically runs 200 to 400ms total. The platform’s synchronous, single-threaded OrderSend() and slower broker-side processing (approximately 50ms versus MT5’s 1 to 2ms) account for most of the difference. MT4 from a home internet connection with decent speeds commonly measures 500 to 700ms, documented across multiple ForexFactory threads. During major news events, execution stretches to seconds or minutes regardless of infrastructure. One confirmed MQL5 forum report logged a single MT4 execution at 150,063ms: two and a half minutes for one order.

The MT4 OrderSend bottleneck. MT4’s OrderSend() is fully synchronous and single-threaded. It blocks all EA code until the server responds with a ticket number or error. Only one order can process at a time. The IsTradeContextBusy() function must be checked before calling, because a second OrderSend() while the first is pending will fail. MT4 also carries a 30-second session timeout. After 30 seconds of inactivity on the trade connection, the next OrderSend() requires re-authentication, adding approximately 500ms to that execution. Keeping the session alive with periodic order modifications or heartbeat requests mitigates this, but it is the kind of operational detail that only surfaces after deployment.

MT5’s OrderSend() is documented as synchronous but behaves semi-asynchronously on live accounts. It blocks until the server acknowledges the order placement, but the deal and price fields in MqlTradeResult may return as zero, requiring polling or OnTradeTransaction() handling for confirmation. One experienced MQL5 developer noted that when OrderSend() returns, the internal bookkeeping in MT5 can still be lagging. This is not a bug. It is the architecture.

A common misconception: MT5’s OrderSendAsync() makes execution faster. It does not. OrderSendAsync() returns immediately after the request is sent, populating only request_id in the result. The actual fill data arrives via OnTradeTransaction() events. The order reaches the broker at the same speed. The only difference is that EA code does not block while waiting for confirmation. This matters for EAs that need to send multiple orders simultaneously. It does not reduce execution latency for a single order.

The deviation parameter and its limitations. The deviation (slippage) parameter in OrderSend specifies maximum acceptable price deviation in points, not pips. On 5-digit brokers, 30 points equals 3 pips. However, this parameter only functions with “Instant Execution” brokers. On ECN/STP brokers using “Market Execution,” the deviation setting is ignored entirely. The order fills at whatever price the market offers at fill time. Scalpers on ECN accounts who believe they have slippage protection through the deviation parameter do not. This is documented in MetaQuotes references but rarely emphasized in broker marketing.

What the data shows about platform choice. The gap between MT4 and MT5 execution is not marginal. At the broker-side processing level alone, the difference is approximately 48ms (50ms versus 1 to 2ms). Combined with MT4’s synchronous blocking, session timeout overhead, and single-threaded constraint, a scalper migrating from MT4 to MT5 on the same VPS may gain more execution speed than a scalper upgrading from a $30/month VPS to a $150/month colocated VPS while staying on MT4. The platform is a larger variable than the hosting tier for most setups.

The Threshold Analysis: Where Latency Stops Mattering

VPS providers sell milliseconds. The question is how much each millisecond is worth. The answer, based on every data source assembled in this research, is that the value drops sharply below 20ms and becomes effectively unmeasurable below 5ms for retail scalping strategies.

1ms vs 5ms. No independently verified study demonstrates a meaningful execution quality difference for retail scalpers operating within this range. Both figures fall within what every source classifies as “excellent.” The difference matters only for institutional HFT firms competing at microsecond granularity for queue position on central limit order books. A retail scalper paying an additional $50 to $100 per month for cross-connected colocation to move from 5ms to 1ms is purchasing a latency improvement that has no documented impact on fill quality at retail order sizes and frequencies.

5ms vs 20ms. Under 5ms is excellent. Under 20ms is, in MassiveGRID’s assessment, “good and functional for most automated trading.” The gap becomes meaningful for aggressive scalping EAs targeting 1 to 3 pip profits on market orders, where each 0.1 pip of slippage compounds across hundreds of daily trades. For a scalper targeting 5 to 15 pip profits per trade, the slippage difference between 5ms and 20ms is buried in the noise of spread variation and LP response time.

20ms vs 100ms. This is the boundary where measurable degradation begins. The only published slippage-versus-latency experiment (covered below) found 1.70 pips of cumulative slippage difference over 120 trades comparing sub-1ms to 75ms latency. A scalping EA targeting 5-pip profits at 100ms latency loses approximately 0.2 pips per trade assuming 2 pips per second of market movement. That is 4% of expected profit on every trade, compounding across hundreds of trades per month into a material cost.

Above 100ms. Clearly problematic for any scalping strategy. Home MT4 setups commonly experience 500 to 700ms total execution. At that level, a scalper targeting 5-pip moves on EUR/USD during London session is routinely entering positions 1 to 3 seconds after the signal, by which time the move may have already delivered most of its range.

The cost hierarchy that VPS marketing omits. For most retail scalpers targeting 5 to 15 pips per trade, three costs stack on every execution. Spread is the dominant, constant cost. EUR/USD typical spread of 0.1 to 1.0 pip consumes 2 to 20% of expected profit on every single trade. This cost is unavoidable and occurs regardless of infrastructure. Commission on raw-spread ECN accounts runs $3 to $7 per round-turn lot, equivalent to 0.3 to 0.7 pips. Combined with spread, total constant costs reach 0.4 to 1.7 pips per trade before latency enters the equation.

Latency-based slippage at sub-20ms is typically 0.01 to 0.1 pips per trade. That is an order of magnitude smaller than spread plus commission. Only above 50 to 100ms does slippage begin to approach spread costs in magnitude. A scalper who has already achieved sub-20ms latency and is considering whether to spend another $80 per month to reach sub-5ms should first calculate whether that $80 would be better spent on a raw-spread ECN account with tighter spreads. In most cases, the spread reduction delivers a larger per-trade improvement than the latency reduction.

The ForexVPS.net experiment: the only published slippage data, and its limitations. Two VPS servers, one in London (sub-1ms ping) and one in New York (approximately 75ms ping), ran the same simple EA trading GBP/JPY on Switch Markets. The EA opened opposite-direction trades every 30 seconds. Over 120 trades each at 0.01 lots, the London VPS accumulated +0.20 pips cumulative slippage (slight positive) while the New York VPS accumulated -1.50 pips (net negative). Total difference: 1.70 pips over 120 trades.

This experiment is cited across VPS provider marketing as evidence that latency costs real money. The directional finding is consistent with market microstructure theory: higher latency increases adverse fill probability. But the study has significant methodological limitations that restrict how far its conclusions can be generalized.

It was conducted by ForexVPS.net, a VPS provider with direct commercial interest in demonstrating that latency affects trading outcomes. The sample size is 120 trades on a single volatile cross pair (GBP/JPY). The strategy, trading every 30 seconds in alternating directions, does not represent any real scalping approach. Market conditions, time of day, and session were not controlled. The extrapolated financial impact ($12,000 to $20,400 per year at 100 lots per month) assumes constant high-volume trading and linear scaling that the data does not support.

No third party has replicated this experiment. No other independently verified slippage-versus-latency study was found in this research. Every citation of the 1.70-pip figure in VPS marketing traces back to this single source. The experiment is useful as a directional indicator. It is not sufficient as a basis for infrastructure spending decisions.

The defensible conclusion. Getting below 20ms is important for scalping. Getting below 100ms is important for all active trading. But the difference between 1ms and 5ms is not meaningfully demonstrated for retail strategies. The largest execution quality gains come from two changes: migrating from home internet to a VPS in the broker’s city, and selecting a broker with fast bridge processing and deep LP access. Both of these changes are available at the $15 to $60 per month VPS tier. The incremental improvement from premium colocation ($80 to $200 per month) exists in theory but is not documented with evidence strong enough to justify the cost for most retail scalpers.

Scalping Strategy Types and Their Real Latency Requirements

Not all scalping strategies need the same infrastructure. A mean-reversion EA placing limit orders at anticipated levels operates in a fundamentally different latency regime than a momentum EA chasing breakouts with market orders. Treating all scalping as equally latency-sensitive leads to either overspending on infrastructure that the strategy cannot exploit, or underspending on infrastructure that the strategy genuinely needs.

Market-making and spread capture. This strategy profits by simultaneously posting bids and offers, capturing the spread while managing inventory risk. It requires sub-1ms latency and realistically sub-microsecond to compete for queue position on central limit order books. Jonathan Kinlay’s mathematical analysis explains the core dynamic: you want to get as near to the front of the queue as you can, as quickly as possible. The problem for retail traders is absolute: institutional HFT firms operating at nanosecond latency with FPGA hardware and colocated infrastructure own this space entirely. No retail VPS, regardless of price or placement, makes market-making viable against participants who are 1,000 to 50,000 times faster. This strategy is functionally unavailable to retail.

Momentum and breakout scalping. These strategies use market orders to chase detected moves, entering as the price breaks a level or accelerates in a direction. Moderately latency-sensitive. A 5 to 20ms network latency is typically adequate because the signal detection quality, whether the EA correctly identifies a genuine breakout versus a false break, matters more than the execution speed for most setups. The latency budget here is less about absolute speed and more about consistency. A VPS that delivers stable 8ms is preferable to one that averages 4ms but spikes to 60ms during London open when breakout signals cluster. Jitter, not average ping, is the relevant metric.

Mean-reversion scalping. These strategies place limit orders at anticipated reversion levels, buying at support zones and selling at resistance zones. Once a limit order sits on the broker’s server, execution depends entirely on broker infrastructure. Client-to-broker latency matters only at the moment of order placement and any subsequent modification. A 10 to 50ms network latency is adequate without significant degradation. The practical implication is concrete: a scalper running a mean-reversion strategy does not need a $60/month same-DC VPS. A $20/month regional VPS that places and modifies orders reliably is sufficient because the time-critical execution happens on the broker’s server, not on the network path.

This extends to a broader insight about order types. Market orders are, as one broker’s documentation states, most vulnerable to slippage because they simply request a fill at the best available price. The price can move between request and fill, and higher latency widens that window. Limit orders remove this vulnerability by specifying the price. The order sits on the server and fills only at the requested price or better. For strategies primarily using limit orders, the sub-5ms optimization yields negligible benefit.

News scalping. This is where latency most clearly matters for retail traders. During NFP, CPI, or FOMC releases, prices can move multiple pips per second. Sub-10ms network latency is critical. However, two factors constrain the advantage. Spreads widen dramatically during news events, often to 5 to 20 pips or more on major pairs. A scalper who enters at sub-10ms latency but pays a 15-pip spread has not gained an edge from speed. Broker processing times also spike during these events because the broker’s bridge and LP infrastructure face the same surge load. Multiple forum reports describe execution times stretching to seconds during NFP regardless of VPS placement. The VPS ensures the network component does not add to the delay. It cannot prevent the broker-side surge.

Grid and martingale on low timeframes. These strategies use predetermined server-side pending orders at fixed intervals. The orders are placed in advance and execute when price reaches them. A 20 to 100ms network latency is acceptable because the time-critical execution is server-side. The infrastructure priority is uptime, not latency. A grid strategy that misses a 2-hour window at 02:00 server time because the home PC went to sleep or the VPS rebooted can desynchronize positions in ways that are expensive to unwind. For these strategies, a $15 to $25/month VPS with 99.99% uptime delivers more value than a $150/month colocated VPS with 0.5ms ping.

The HFT Boundary: Where Retail Scalping Ends

The gap between retail VPS scalping and institutional high-frequency trading is not a spectrum. It is a discontinuity. Understanding where the boundary sits prevents two mistakes: overspending on infrastructure that cannot close the gap, and undervaluing the infrastructure tier that is actually appropriate for retail latency.

The numbers are concrete. FPGA-based institutional systems achieve 100 to 500 nanosecond tick-to-trade latency. That is nanoseconds, not milliseconds. Optimized software with kernel bypass (bypassing the operating system’s network stack entirely to read packets directly from the NIC) operates at 1 to 10 microseconds. The best retail VPS achieves 300 to 5,000 microseconds, which is 0.3 to 5 milliseconds. The gap between the fastest retail setup and the slowest institutional setup is a factor of 30. The gap between a typical retail VPS and a competitive FPGA system is a factor of 1,000 to 50,000.

To put this in physical terms: in the time it takes a retail VPS to process and send one order, an FPGA system has processed and sent between 1,000 and 50,000 orders. These are not competing in the same market. They are operating in different temporal dimensions of the same price feed.

What that infrastructure costs. FPGA hardware runs $20,000 to $80,000 per card, with six-figure development costs and typically 3 or more years of development time to build competitive firmware. AMD’s Alveo UL3422 FinTech accelerator, one of the current generation cards, achieves 7x latency reduction over its predecessor. The hardware is the smaller expense. Full HFT infrastructure setup, including colocation, network, software development, and regulatory compliance, runs $1 to $5 million with ongoing costs of $50,000 to $200,000 per month. CME Group colocation alone costs $12,000 per month for a 10G handoff plus $2,000 setup.

The lengths firms go to illustrate the competitive intensity at this level. Jump Trading purchased a 31-acre plot of land for $14 million to place a microwave antenna with line-of-sight to CME’s data center in Aurora, Illinois. The microwave link shaves approximately 4 milliseconds off the fiber route between Chicago and New Jersey. At the institutional level, 4 milliseconds justifies a $14 million real estate purchase.

Why the boundary matters for VPS decisions. A retail scalper considering a $150/month cross-connected VPS versus a $30/month same-city VPS is deciding whether 3ms of improvement justifies $120/month. That is a legitimate infrastructure question with a calculable answer based on trade frequency and pip targets. A retail scalper considering whether “better infrastructure” can make market-making or latency arbitrage viable is asking a different question entirely. The answer is no. Not because the VPS is inadequate, but because the strategies available at 0.3 to 5ms latency are fundamentally different from those available at 100 to 500 nanoseconds. A VPS that is 10 times faster than another VPS is still 100 to 5,000 times slower than the institutional floor.

The retail edge does not come from speed. It comes from strategy quality: identifying setups that institutional participants are not competing for, trading on timeframes where microsecond advantages are irrelevant, and selecting brokers whose execution model does not penalize retail order flow. A scalper with a $30/month VPS running a well-tested mean-reversion EA on a broker with deep LP access and no last look will outperform a scalper with a $200/month colocated VPS running an untested breakout EA on a broker with thin liquidity and artificial dealer delays. The infrastructure is a multiplier. It multiplies whatever edge the strategy has, including zero.

VPS Configuration for Minimum Latency

A VPS placed in the right data center with the wrong configuration wastes the proximity advantage. The network stack, power management, and MetaTrader settings on a default Windows Server installation introduce latency that is entirely avoidable. These are not marginal optimizations. Disabling Nagle’s algorithm alone can recover 200 to 300ms on small packet dispatch.

Nagle’s algorithm: the single highest-impact configuration change. Nagle’s algorithm batches small TCP packets to reduce network overhead. It was designed for an era when bandwidth was scarce and the overhead of individual packet headers mattered. A trading order is a small packet. Nagle’s algorithm holds it, waiting to see if more data will follow so it can batch them together, introducing up to 200 to 300ms of delay on individual sends. Combined with Delayed ACK (the receiving side’s equivalent optimization, where the receiver waits before acknowledging packets), the pair can add up to 500ms of combined delay on a single order round-trip.

Disabling both requires two Windows Registry changes under the network adapter’s GUID at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces{adapter-GUID}. Create two DWORD values: TcpNoDelay set to 1 and TcpAckFrequency set to 1. A reboot applies the change. On a fresh Windows Server VPS with default settings, this is the first thing to configure before installing MetaTrader.

Power management. The default Windows Server power plan is “Balanced,” which throttles CPU frequency during low-load periods to save energy. On a data center VPS where the trader is paying for the full CPU allocation, this throttling adds microseconds of latency on every tick processing cycle as the CPU ramps back to full frequency. Set the power plan to “High Performance” via the Control Panel or PowerShell. Additionally, disable CPU parking and set minimum processor state to 100%. On a VPS where the EA runs 24/5, the CPU should never be in a power-saving state.

Service cleanup. A default Windows Server installation runs services that consume RAM and CPU without contributing to trading. Print Spooler, Windows Search and Indexing, Superfetch (SysMain), scheduled defragmentation, and Windows Defender real-time scanning all consume resources. Disabling these saves 50 to 150MB of RAM and, more importantly, reduces CPU contention during tick bursts. Windows Defender specifically should have exclusions added for MetaTrader directories rather than being fully disabled, because an unprotected server connected to the internet introduces a different category of risk.

MetaTrader-specific optimization. Four settings have the most impact on execution latency. First, remove unused symbols from Market Watch. Each symbol in the list generates tick data that MetaTrader processes, consuming CPU cycles even if no chart or EA is using it. A default Market Watch with 200+ symbols generates continuous background load. Strip it to the symbols actively traded. Second, close charts not running active EAs. Each open chart processes ticks independently. Third, reduce “Max bars in history” from the default 512,000 to 10,000 to 50,000, and “Max bars in chart” to 10,000. The cross-article verified impact: 500,000 bars across 23 M1 pairs consumes approximately 1 GB of RAM; reducing to 5,000 bars drops that to approximately 25 MB, a 40x reduction. Fourth, disable visual effects like “Show trade levels” that trigger rendering updates on every tick.

RAM allocation should follow the platform: minimum 512MB to 1GB per MT4 instance, 2 to 4GB per MT5 instance. The 25% free RAM rule applies at all times. When available RAM drops below 25%, the operating system begins paging to disk. Swap is approximately 100x slower than RAM. On a VPS running close to its RAM ceiling during a high-volatility session, the first page fault turns a 2ms operation into a 200ms operation.

The noisy neighbor problem. On shared VPS infrastructure, other tenants’ resource usage affects your performance. During high-volatility events, when multiple traders on the same physical host simultaneously need more CPU for tick processing, CPU contention creates latency spikes. This is the primary source of jitter in VPS environments. KVM hypervisors provide full hardware-level isolation, preventing CPU theft between tenants. Hyper-V offers dedicated CPU and RAM allocations. The practical test is simple: if execution times are stable during quiet sessions but spike during London open or NFP, the VPS is likely experiencing noisy-neighbor contention, and a dedicated server or a provider with stronger isolation is the fix.

Measuring real execution latency. The MetaTrader status bar shows network ping only. It does not measure EA computation, terminal processing, broker bridge, LP fill, or confirmation return. A status bar reading of 0.5ms and a journal entry of 40ms are not contradictory. They measure different things.

Three measurement methods provide accurate execution data. The journal itself shows total round-trip with millisecond precision in MT5 (the “done in X ms” entry). Programmatically, GetMicrosecondCount() before and after OrderSend() provides 1-microsecond precision. GetTickCount() is insufficient for this purpose because it has only 15.6ms precision, which is coarser than the latency being measured. For server-side measurement, calculating ORDER_TIME_DONE_MSC minus ORDER_TIME_SETUP_MSC gives the broker’s internal execution time, which isolates the broker-side components from the network components.

The practical diagnostic approach: build or install an EA that simultaneously times OrderSend() round-trips and network pings. If network ping is 2ms but OrderSend() takes 60ms, broker processing accounts for approximately 56ms (60ms minus two network trips of 2ms each). This tells the trader whether the bottleneck is the VPS (network), the broker (bridge/LP), or the EA (computation). Without this measurement, every infrastructure upgrade is a guess.

Broker Execution Data and What It Means for VPS Placement

The VPS controls network latency. The broker controls everything else. A 1ms VPS connection to a broker with a 50ms bridge delivers 52ms round-trip. A 5ms VPS connection to a broker with a 3ms execution engine delivers 13ms round-trip. Choosing the right broker and placing the VPS in the right location relative to that broker’s infrastructure are two halves of the same decision. Making either one in isolation wastes money.

Published broker execution speeds. These figures come from broker self-reporting and independent tests. Source quality varies significantly and is noted for each.

IC Markets reports 35 to 40ms average execution. This is the broker’s own, relatively conservative figure. Affiliate sites cite 0.35ms for IC Markets, but that figure likely measures only server-side processing time, not total execution round-trip. Independent testing by QuantVPS measured 134ms for limit orders. Colocated VPS users on MQL5 forums report sub-20ms total. The disparity between sources reflects different measurement points in the chain, which is exactly why the six-component breakdown in Section 2 exists.

Pepperstone reports approximately 30ms average. NYC Servers measured 30 to 60ms. QuantVPS measured 77ms for limit orders. OANDA reports 12ms average, with TopAsiaFX measuring 8.2ms. OANDA is a market maker, so fills happen internally without LP routing, which explains the faster average. LMAX Exchange reports approximately 3ms average. LMAX operates a central limit order book with no last look and strict price/time priority. Its execution speed reflects the absence of the LP hold window that adds 10ms or more at most other venues. BlackBull Markets ranked first overall in CompareForexBrokers’ 2026 independent test of 20 MT4 brokers, finishing first in limit orders and third in market orders.

A note on independent testing methodology: CompareForexBrokers subtracted network latency to produce location-independent execution comparisons. Their Australian test location added 230 to 300ms of network latency, making raw total round-trips 300 to 500ms with some trades exceeding 1 second. With a cross-connected VPS, network latency dropped to 0.33ms (LD4) and 0.37ms (NY4). The difference between 300ms and 0.37ms is the VPS value proposition in a single data point.

Where the brokers are. Equinix data centers host the highest concentration of forex broker infrastructure. Three locations matter most.

NY4 and NY5 in Secaucus, New Jersey serve as the primary US forex hub. Confirmed brokers present include IC Markets, Pepperstone, and LMAX. Multiple VPS providers operate in these facilities including BeeksFX, TradingFXVPS, ForexVPS.net, and NYCServers.

LD4 and LD5 in Slough, west of London, host the highest concentration of forex broker servers globally, processing approximately 35% of daily forex volume during London sessions. The same VPS providers maintain presence here.

TY3 in Tokyo serves as the premier APAC financial data center. Singapore-to-Tokyo latency runs 70 to 80ms, which means a Singapore-based trader connecting to a TY3 broker faces a network floor that no VPS placement can reduce below approximately 35 to 40ms one-way.

Cross-connect pricing within these facilities runs $350 to $550 per month for dedicated fiber between racks. This is on top of VPS or server costs and is typically only available through VPS providers who already have rack space in the facility.

How to determine your broker’s data center. Four methods, in order of reliability. Check the broker’s VPS partnership page, which often lists “Equinix NY4” or “LD4” explicitly. Ask broker support directly. Use ping or traceroute to the broker’s server IP from multiple geographic locations and identify the lowest-latency region. Check VPS provider broker latency pages: ForexVPS.net, FXVM, and Liquidity Connect publish broker location mappings. In MetaTrader, right-click the connection status in the bottom bar and select “Rescan Servers” to display latency to all available server endpoints.

MetaQuotes Ultency: the infrastructure development that changes Component D. The most significant shift in broker execution infrastructure for 2026 does not come from VPS providers. It comes from MetaQuotes. Ultency is a native matching engine built into MetaTrader 5 that eliminates the need for third-party bridges like PrimeXM XCore, oneZero Hub, or Gold-i. It provides liquidity aggregation, order matching, and risk management directly within MT5.

The pricing model disrupts the bridge market: $1 per $1 million traded with no fixed monthly fees, compared to the significant fixed costs of traditional bridge providers. Ultency is hosted in Equinix LD4, NY4, HK1, SG1, and TY3. Adopters already include FxPro (launch partner), LMAX Group, Vantage, and BitDelta Pro. BitDelta Pro measured 0.26ms latency after Ultency integration in December 2025.

For scalpers, the implication is straightforward. If your broker adopts Ultency, Component D (broker bridge processing) shrinks from the typical 1 to 50ms range to sub-millisecond. This improvement happens on the broker’s side. The VPS configuration does not change. The VPS still controls Component C (network latency). But the total execution time drops because the broker’s contribution to the chain gets smaller. A scalper on an Ultency-integrated broker with a standard $30/month same-city VPS may achieve better total execution than a scalper on a legacy-bridge broker with a $150/month cross-connected VPS.

The infrastructure tier summary. Five tiers exist, each with a documented latency range and cost.

Institutional colocation with own hardware achieves sub-100 microsecond to sub-1ms latency at $12,000 or more per month plus setup costs. This is outside retail scope.

A premium VPS cross-connected in Equinix achieves 0.3 to 2ms at $40 to $200 per month. This tier is justified for high-frequency scalpers executing hundreds of market-order trades per month on sub-H1 timeframes.

A standard forex VPS in the same city as the broker achieves 1 to 10ms at $15 to $60 per month. This is the tier where most retail scalpers should operate. It crosses the sub-20ms threshold where further reductions have diminishing returns.

A general cloud VPS from providers like Vultr or DigitalOcean achieves 5 to 50ms at $5 to $30 per month. Adequate for strategies that are not latency-sensitive (mean-reversion with limit orders, grid strategies). Not optimized for MetaTrader and may lack the Windows licensing, NVMe storage, and dedicated CPU allocation that forex-specific providers include.

Home internet achieves 50 to 300ms at the existing ISP cost. Adequate for swing trading and position trading. Not adequate for scalping.

FAQ

What latency do I actually need for scalping?

Sub-20ms network latency is the meaningful threshold. Below that, spread and commission dominate execution costs at 10 to 100 times the magnitude of latency-based slippage. No independently verified study demonstrates a measurable execution quality difference between 1ms and 5ms for retail scalpers. A same-city VPS at $15 to $60 per month achieves 1 to 10ms, which crosses the threshold comfortably. Premium colocation at $80 to $200 per month shaves additional milliseconds but the per-trade improvement is not documented with evidence strong enough to justify the cost for most retail setups.

Does the MetaTrader status bar show my real execution speed?

No. The status bar displays network ping only, which is Component C in the six-stage execution chain. One MQL5 forum user measured 0.5ms on the status bar but 40ms in the trade journal. The journal figure includes EA computation, terminal processing, broker bridge, LP fill, and confirmation return. To measure real execution latency, use GetMicrosecondCount() before and after OrderSend() for client-side timing, or calculate ORDER_TIME_DONE_MSC minus ORDER_TIME_SETUP_MSC for server-side execution time. GetTickCount() is insufficient because its 15.6ms precision is coarser than the latency being measured.

Is MT5 faster than MT4 for scalping?

At the broker-side processing level, substantially. MT5 internal server processing runs approximately 1 to 2ms versus MT4’s approximately 50ms. MT5 also supports multithreading and OrderSendAsync() for non-blocking code. However, OrderSendAsync() does not reduce execution speed for individual orders. It prevents EA code from blocking while waiting for confirmation, which matters for EAs submitting multiple simultaneous orders but not for single-order scalpers. MT4 carries additional overhead: fully synchronous single-threaded OrderSend(), a 30-second session timeout adding approximately 500ms to the first order after idle periods, and a maximum tick processing rate of approximately 12 per second. Migrating from MT4 to MT5 on the same VPS may deliver a larger execution improvement than upgrading from a $30/month VPS to a $150/month colocated VPS while staying on MT4.

What is MetaQuotes Ultency and does it change VPS requirements?

Ultency is a native matching engine built into MetaTrader 5, launched November 2025. It eliminates third-party bridge dependencies (PrimeXM, oneZero, Gold-i) by handling liquidity aggregation, order matching, and risk management directly within MT5. BitDelta Pro measured 0.26ms latency after integration. Pricing runs $1 per $1 million traded with no fixed monthly fees. It does not change VPS requirements. The VPS still controls network latency (Component C). Ultency reduces Component D (broker bridge processing), which benefits all traders on Ultency-integrated brokers regardless of VPS tier. Adopters include FxPro, LMAX Group, and Vantage.

Can I compete with HFT firms by getting a better VPS?

No. The gap is structural, not incremental. Institutional HFT operates at 100 to 500 nanoseconds using FPGA hardware ($20,000 to $80,000 per card), colocation ($12,000+/month), and custom infrastructure ($1 to $5 million setup with $50,000 to $200,000/month ongoing). The best retail VPS achieves 0.3 to 5ms, which is 1,000 to 50,000 times slower. The strategies available at retail latency are fundamentally different from those at institutional latency. Market-making and latency arbitrage require nanosecond execution. Momentum scalping, mean-reversion, and news trading operate at millisecond latency and are the strategies where retail VPS infrastructure provides genuine value.

Should I disable Nagle’s algorithm on my VPS?

Yes. This is the single highest-impact configuration change for latency-sensitive trading on Windows Server. Nagle’s algorithm batches small TCP packets, introducing up to 200 to 300ms of delay on trading order dispatch. Combined with Delayed ACK on the receiving side, total added delay can reach 500ms. Disable both by creating two DWORD registry values under the network adapter’s GUID: TcpNoDelay set to 1 and TcpAckFrequency set to 1. A reboot is required. On a fresh VPS with default settings, this should be the first configuration change before installing MetaTrader.

References

• William Roeder, MQL5 forum moderator. Statement on EA computation latency: the microseconds the EA takes are irrelevant compared to the 20 to 200 milliseconds the network takes. Used in Section 2 to contextualize Component A (EA computation) as negligible relative to network and broker processing. Source quality: experienced forum moderator with extensive posting history on MQL5 execution mechanics.
• MetaQuotes. MQL5 Reference documentation. Confirms OnTick() tick discard behavior: if OnTick is still processing when a new tick arrives, the new tick is ignored. Documents OrderSend() and OrderSendAsync() behavior, MqlTradeResult structure, GetMicrosecondCount() precision (1 microsecond), GetTickCount() precision (approximately 15.6ms), ORDER_TIME_DONE_MSC and ORDER_TIME_SETUP_MSC fields, and CopyBuffer() initialization overhead. Used throughout this article for all platform-level execution mechanics. Source quality: primary platform documentation.
• MQL5 forum user measurement. Reported end-to-end execution chain: “Execution time according to my ECN broker (to aggregator and back) = 16 to 20ms. From home super PC = 141ms (minus 110ms latency = 31ms execution). VPS minimum execution stable at 45 to 61ms.” Used in Sections 2 and 3 to demonstrate that broker processing (16 to 20ms) is the floor regardless of client infrastructure. Source quality: single user report, not independently replicated, but internally consistent and directionally aligned with broker execution data from other sources.
• MQL5 forum user, Equinix NY colocated measurement. Reported approximately 40ms total execution on MT5 with IC Markets at 0.5ms ping. Used in Section 3 as the best-case benchmark. Source quality: single user report. The figure is consistent with the 16 to 20ms broker processing floor plus sub-1ms network round-trip plus LP fill time.
• MQL5 forum, MT4 execution outlier. Confirmed 150,063ms (2.5 minutes) single MT4 order execution. Used in Section 3 to illustrate extreme tail latency. Source quality: journal-confirmed case report with millisecond precision timestamp.
• MQL5 forum user, tick skip measurement. Measured 0.1 to 0.2% tick skip rate on non-native symbols in a multicurrency EA, with processing delays averaging 103 to 118ms correlated to skipped ticks. Used in Section 2 for the tick discard analysis. Source quality: single measurement with documented methodology. FXPIG broker representative separately confirmed MT4 processes approximately 12 ticks per second maximum.
• MQL5 forum developer, OrderSend semi-asynchronous behavior. Noted that when OrderSend() returns on MT5 live accounts, internal bookkeeping can still be lagging, with deal and price fields returning as zero. Used in Section 3 for the MT5 OrderSend mechanics analysis. Separately, forum consensus confirms OrderSendAsync() does not reduce execution speed, only prevents code blocking. Source quality: experienced developer reports, consistent across multiple independent forum threads.
• ForexFactory thread 337102 and related threads. Document MT4 home internet execution times of 500 to 700ms and slippage reports of 36 to 40 pips on GBP during major news events. Used in Section 3 for home internet benchmark data and in Section 4 for news-event slippage context. Source quality: community reports from active traders, multiple independent confirmations of the 500 to 700ms range.
• ForexVPS.net. Slippage versus latency experiment. Two VPS servers (London sub-1ms, New York approximately 75ms) ran the same EA trading GBP/JPY on Switch Markets, 120 trades each at 0.01 lots. London VPS: +0.20 pips cumulative slippage. New York VPS: -1.50 pips. Total difference: 1.70 pips. Used in Section 4 as the only published slippage-versus-latency study, with critical assessment. Source quality: commercially interested. ForexVPS.net is a VPS provider with direct financial interest in demonstrating that latency affects trading outcomes. Sample size is 120 trades on a single volatile pair. Strategy (alternating directions every 30 seconds) does not represent real scalping. Not independently replicated. Directional finding is consistent with market microstructure theory.
• CompareForexBrokers. 2026 independent execution test of 20 MT4 brokers. Subtracted network latency for location-independent comparison. BlackBull Markets ranked first overall. Australian test location added 230 to 300ms network latency. Cross-connected VPS reduced network latency to 0.33ms (LD4) and 0.37ms (NY4). Used in Section 8 for independent broker execution benchmarks and the VPS proximity value demonstration. Source quality: independent review site with documented methodology. Testing conducted from a single geographic location.
• IC Markets. Self-reported 35 to 40ms average execution speed. Used in Section 8 for broker execution comparison. Source quality: broker self-reporting. More conservative and credible than affiliate-cited figures of 0.35ms, which likely measure server-side processing only.
• LMAX Exchange. Reports approximately 3ms average execution with no last look and strict price/time priority. Used in Sections 2 and 8 for the fastest-execution broker benchmark and the no-last-look model comparison. Source quality: broker self-reporting, but the no-last-look model is independently verified through regulatory filings and industry documentation.
• OANDA. Reports 12ms average execution. TopAsiaFX independently measured 8.2ms. Used in Sections 2 and 8 as the market-maker execution speed benchmark. Source quality: broker self-reporting. TopAsiaFX is an affiliate site. The faster speed is directionally consistent with the B-book model (internal matching, no LP routing).
• MetaQuotes. Ultency matching engine documentation and announcements. Launched at Finance Magnates London Summit, November 2025. Native MT5 matching engine eliminating third-party bridge dependencies. Pricing: $1 per $1 million traded, no fixed monthly fees. Hosted in Equinix LD4, NY4, HK1, SG1, TY3. Adopters: FxPro, LMAX Group, Vantage, BitDelta Pro. BitDelta Pro measured 0.26ms latency post-integration (December 2025). Used in Sections 2, 8, and FAQ for Component D analysis and the broker infrastructure development assessment. Source quality: primary vendor documentation and adopter-reported measurements. BitDelta Pro figure is from a single adopter and commercially interested.
• MetaQuotes. Virtual Hosting specifications (mql5.com/en/vps). Official figures: 84% of broker servers accessible under 3ms, 96% under 10ms. An older publication states 70% under 3ms and nearly 20% under 1ms. Pricing $10 to $15/month. Over 140,000 traders have used the service. Limitations: no RDP, no DLL, one account per instance, 3 GB maximum. Used to correct the commonly misquoted “96% under 3ms” claim. Source quality: primary vendor documentation with two time-period figures reflecting expanding network coverage.
• Cboe FX. Reduced last look threshold from 35ms to 10ms in October 2025. Used in Section 2 for LP fill latency trends. CME EBS platform averaged 12ms last look hold time in 2022, with the industry average dropping to approximately 10ms by 2025. Source quality: exchange-level documentation and industry reporting via Databento microstructure guide.
• Jonathan Kinlay. Mathematical analysis of queue position and latency in market-making. Explains the relationship between latency and queue priority on central limit order books. Used in Section 5 to establish why market-making requires sub-microsecond latency. Source quality: published quantitative finance researcher with peer-reviewed work on market microstructure.
• MassiveGRID. VPS provider documentation and latency guidance. Recommends “consistently below 10ms” for optimal scalping. Documents Nagle’s algorithm delay (200 to 300ms on small packets), TcpNoDelay and TcpAckFrequency registry settings, Delayed ACK combined delay (up to 500ms), power plan impact, service cleanup (50 to 150MB RAM savings), NIC latency (standard 20 to 50 microseconds, kernel bypass 1 to 5 microseconds), and KVM isolation. Used in Sections 4 and 7 for the latency threshold benchmark and VPS configuration guidance. Source quality: commercially interested (VPS provider). Configuration guidance is technically sound and consistent with Microsoft networking documentation. Latency threshold recommendation is conservative and aligned with other sources.
• VPS provider latency claims (all commercially interested). ForexVPS.net: “as low as 0.5ms” from 22 locations, approximately $35 to $40/month. BeeksFX: average 1ms globally, X-Connect measured at 0.510ms ICMP ping, from approximately $40/month (LSE-listed, ticker BKS, FY2025 revenue £35.9 million). FXVM: 0.3 to 5ms across 16 locations, from $11.90/month, Trustpilot 4.8/5 from approximately 4,000 reviews. Same parent company as ForexVPS.net (ThinkHuge Ltd). TradingFXVPS: 0.30ms average from Equinix, AMD Ryzen 9950X, 10Gbps SolarFlare NICs, from approximately $17.50/month annual. All figures are provider-sourced marketing claims and have not been independently verified in this research. ForexVPS.net and FXVM experienced a simultaneous 24-hour New York outage in August 2025. Used contextually but not cited as verified benchmarks in the article body.
• FXCM. January to November 2025 slippage statistics. 30.83% of all orders received positive slippage, 14.64% negative, approximately 55% zero. Limit and limit entry orders: 74.58% positive slippage. Stop and stop entry orders: 57.42% negative slippage. Not directly cited in the article body but used to validate the directional finding that slippage at sub-20ms latency is typically 0 to 0.3 pips under normal conditions. Source quality: broker-published, covers a large sample over 11 months. Represents one broker’s execution environment.
• Moallemi & Saglam (2013). “The Cost of Latency in High-Frequency Trading,” Operations Research. Provides a closed-form expression for latency cost as a function of latency, price volatility, and bid-offer spread. Key finding: the marginal benefit of reducing latency increases as latency approaches zero, meaning diminishing returns work in reverse at the lowest latencies. Calibrated on NYSE stocks, not forex, and focused on institutional trading. Used directionally to support the threshold analysis but not cited as directly applicable to retail forex. Source quality: peer-reviewed academic research.
• Chaboud, Chiquoine, Hjalmarsson & Vega (2014). “Rise of the Machines,” Journal of Finance. Federal Reserve Board researchers using EBS/ICAP data. Found that algorithmic trading improves price efficiency but may impose higher adverse selection costs on slower traders. Non-algorithmic order flow accounts for a larger share of exchange rate return variance. Used contextually for the institutional versus retail execution quality framework. Source quality: peer-reviewed academic research using proprietary data.
• Bank for International Settlements. Triennial Central Bank Survey, April 2025. Global FX turnover reached $9.51 trillion daily, up from $7.5 trillion. EBS spot volumes increased 35% between April 2022 and April 2025. Used as market context. Source quality: primary institutional data source with standardized methodology across central banks.
• MetaTrader 5. Build 5430 (November 2025) replaced GDI graphics with Blend2D engine. Build 5540 (January 2026) added ONNX GPU/CUDA acceleration. MT5 surpassed 2 million active trading accounts in 2025. Used contextually for 2026 platform development status. Source quality: official MetaQuotes release notes.

Editorial Note

This article covers the infrastructure components of scalping execution latency. It is not financial advice and does not recommend any scalping strategy, broker, or trading approach. Whether a scalping strategy is profitable depends on the strategy’s edge, market conditions, broker execution model, LP depth, and the trader’s risk management, none of which are within the scope of VPS infrastructure.

Latency figures throughout this article are reference ranges compiled from MQL5 forum measurements, broker self-reported data, independent test results, VPS provider documentation, and academic research. Actual execution times vary based on broker bridge technology, LP response conditions, market volatility, VPS provider hardware and hypervisor configuration, network routing, and time of day. No latency figure in this article should be treated as a guaranteed or reproducible benchmark.

Broker execution speed figures are self-reported unless otherwise noted. IC Markets, Pepperstone, OANDA, and LMAX figures come from broker documentation or marketing materials. The CompareForexBrokers 2026 test used documented methodology but was conducted from a single geographic location. Affiliate-sourced figures (TopAsiaFX) are flagged where cited. All broker execution data reflects conditions at the time of measurement and may not represent current performance.

Every VPS provider latency claim cited in this article comes from a commercially interested source. ForexVPS.net, BeeksFX, FXVM, TradingFXVPS, and MassiveGRID are VPS providers whose business depends on demonstrating that latency matters and that their infrastructure reduces it. Their configuration guidance is technically sound and consistent with independent documentation, but their latency figures are marketing claims, not independently verified benchmarks. The ForexVPS.net slippage experiment is a provider-conducted marketing study with a 120-trade sample on a single currency pair. It has not been replicated. Its directional finding is consistent with market microstructure theory, but the extrapolated financial impact figures should not be used as a basis for infrastructure spending decisions.

This article is published on a VPS provider’s website. The same evaluation criteria and transparency standards apply to all infrastructure tiers discussed, including the finding that most retail scalpers operating at sub-20ms latency should prioritize strategy quality, broker selection, and spread minimization over further latency reduction. The article does not recommend premium colocation where the evidence does not support the cost for the reader’s likely use case. The honest assessment is that a standard forex VPS in the same city as the broker’s data center, at $15 to $60 per month, delivers the measurable threshold (sub-20ms) beyond which further VPS spending produces diminishing returns that are not documented in any independent study.