Order flow trading platform latency: a 3-step ping test
For an order flow trader, latency is not a single number. It is a chain of delays between the exchange, the data vendor, the trading platform, the broker, and the screen in front of you.
Garrett Croft·Updated: August 06, 2026·18 min read
Order Flow Trading Platform Latency: A 3-Step Ping Test
A simple ICMP ping can measure one small part of that chain, but it cannot tell you whether a DOM update arrived late, whether the platform is still processing the previous burst of data, or whether an order acknowledgment took longer than usual.
That distinction matters most when the strategy is built around a small expected move. A few milliseconds may be irrelevant to a position trader and meaningful to a scalper reacting to a changing bid, offer, or queue. But the test has to measure the right thing. A TCP handshake is not an order fill, and a network percentile is not automatically an order-level percentile.
The practical approach is to use a three-step test:
1. identify the connections the platform is actually using;
2. measure TCP responsiveness on relevant endpoints;
3. interpret the distribution without confusing network behavior with execution performance.
The result is not a guarantee of fill quality. It is a more useful baseline than pressing ping and assuming the displayed number describes the entire trading path.
Why Standard ICMP Pings Fail to Measure Execution Speed
The Windows ping command sends ICMP Echo Request packets and reports the round-trip time for the response. That is useful for checking whether a host is reachable and whether the route is broadly stable. It is not a complete test of an order flow trading platform.
Three limitations are especially important.
ICMP may not follow the trading path
A broker, data vendor, or hosting provider may block ICMP, rate-limit it, or treat it differently from application traffic. Even when the destination answers, the response may be handled by a network device rather than the service that receives market-data or order-entry traffic.
A successful ICMP response therefore confirms only that a particular host or network path answered an ICMP request. It does not confirm that the TCP port used by the platform is available, responsive, or routed in the same way.
ICMP does not exercise the application protocol
Order flow platforms such as Bookmap, Sierra Chart, Jigsaw, and ATAS can maintain several different connections at once. Depending on the provider and configuration, those connections may carry market data, authentication traffic, account information, or order messages over TCP, TLS, WebSocket, FIX, or a proprietary protocol.
ICMP does not perform a TCP three-way handshake. It does not negotiate TLS, establish an authenticated session, or pass through the application layer. It also does not reproduce the work required to decode, queue, aggregate, and render a high-volume stream of depth updates.
That makes a low ICMP result compatible with a slow or unstable platform experience. The network route may be healthy while the endpoint, protocol, local machine, or feed handler is under pressure.
ICMP measures transit, not processing
A 12 ms ICMP result says that the request and response completed in roughly that time under the conditions of the test. It does not say how long a market-data message took to move from an exchange feed to the vendor, from the vendor to the platform, or from the platform's internal queue to the chart.
The same limitation applies to order entry. A TCP test cannot measure broker validation, risk checks, exchange routing, queue position, matching, or the time taken to return an execution report. Those stages require platform or broker timestamps, and in many retail setups the trader cannot observe every timestamp in the path.
ICMP ping measures packet transit. Order flow latency is a chain of transport, processing, rendering, routing, and acknowledgment delays. Treating them as the same metric creates a clean-looking number with very little diagnostic value.
Step 1: Identifying Active Broker Connections with TCPView
Before measuring latency, find out which processes and endpoints the platform is using. TCPView, part of Microsoft's Sysinternals tools, provides a live view of TCP and UDP connections on a Windows machine.
The purpose is not to assume that every visible connection is a market-data endpoint. The purpose is to build a map of the platform's current network activity and then verify which connections are relevant.
The basic procedure
1. Launch TCPView before opening the platform, so that new connections are easier to spot.
2. Start the order flow platform and connect to the live account or data feed.
3. Wait until the DOM, footprint, ladder, or heatmap is receiving live updates.
4. Filter or sort the list by the platform process name. Examples might include Bookmap.exe, SierraChart.exe, or the executable used by the relevant Jigsaw installation.
5. Note the remote address, remote port, connection state, and process associated with each connection.
6. Repeat the observation after disconnecting and reconnecting the feed. An endpoint that appears and disappears with the data session is more useful than an address that remains present for licensing or background services.
A platform may use different endpoints for market data, order entry, account status, news, authentication, and software updates. Many services also use port 443, so the port number alone rarely identifies the function. A familiar port is a clue, not proof.
| Connection type | What may be visible | Why it matters |
|---|---|---|
| Market-data session | Sustained traffic while the DOM or chart is active | Relevant to feed delivery and update continuity |
| Order-entry session | Short bursts around order submission, cancellation, or acknowledgment | Relevant to transport responsiveness, but not sufficient to measure fill time |
| Authentication or account session | Activity at login or during periodic session checks | Usually not a useful target for continuous latency testing |
| Platform service or update connection | Background traffic unrelated to live trading | Can create a misleading target if mistaken for the feed |
Packet counters can help identify active traffic, but they should not be treated as a definitive classification method. A market-data stream may be compressed, multiplexed, or handled through a gateway shared with other services. The most reliable confirmation comes from the platform's own documentation, connection logs, or a controlled comparison: stop the feed, observe which connection changes, then restore it.
Platform-specific cautions
Some platforms publish diagnostic or data-service endpoints. Those can be useful for establishing a baseline, but a diagnostic server is not automatically equivalent to the production route used by a live account. Test it separately and label the result accordingly.
Likewise, a platform's on-screen latency indicator may describe feed delay, internal processing delay, or a vendor-defined health state. It can be valuable for monitoring, but it is not necessarily comparable to a TCP round-trip measurement. Record what the indicator means before using it in a comparison.
Do not test only the first IP address you see and then conclude that the entire platform has that latency. Connections can change after a restart, login, provider failover, or regional routing event. Capture the endpoint, time, connection state, and platform mode alongside the measurement.
Step 2: Executing Precise TCP-Based Latency Tests with PsPing
PsPing, another Sysinternals utility, can send TCP-based probes to a specified address and port. Unlike ICMP, a TCP probe tests whether the target port can accept a TCP connection and measures the time associated with that exchange.
That makes PsPing a better tool for testing transport responsiveness than the standard ping command. It still has limits: it does not log in, subscribe to market data, submit an order, or reproduce the broker's complete execution path.
Command syntax
psping -4 -t [IP]:[PORT]
The relevant options here are:
-4forces IPv4, which keeps the comparison consistent if the system can use both IPv4 and IPv6;-truns the test continuously until you stop it with Ctrl+C.
Open PowerShell or Command Prompt, move to the directory containing PsPing, and run the test against the endpoint identified in TCPView. If the port refuses connections, times out, or behaves differently from the platform's established session, stop and reassess the target rather than interpreting the failure as a latency result.
Build a repeatable sample
A single run is almost useless for evaluating an order flow software latency profile. Network conditions vary with the route, local traffic, provider load, and time of day. Run a sustained sample, record the output, and repeat it under at least two different conditions:
- while the platform is connected but relatively quiet;
- during a period when the instrument is actively publishing depth updates;
- after a reconnect or platform restart, if cold-start behavior is relevant;
- from the same machine and network that will be used for trading.
The exact sample count matters less than consistency. A short run can miss a transient queue or route change; an extremely long run can combine several unrelated conditions into one distribution. Keep a time log so that a spike can be compared with platform messages, feed interruptions, or local CPU activity.
If you redirect output to a file, use a consistent command and preserve the raw result:
psping -4 -t [IP]:[PORT] -l 64 -q > latency_log.txt
The output is a transport sample. It is not an execution report. That label should stay attached to it when the data is later analyzed.
Read the summary without mislabeling it
PsPing typically reports a minimum, maximum, average, and a measure of dispersion. These figures answer different questions.
| Metric | Correct interpretation |
|---|---|
| Minimum | A best observed result in the sample; not a guaranteed floor |
| Arithmetic mean | The sum of observed values divided by the number of observations |
| p50 or median | The middle observation after sorting the sample |
| Maximum | The largest observed result; highly sensitive to one-off events |
| Standard deviation | A measure of dispersion around the arithmetic mean |
The arithmetic mean and p50 are not interchangeable. They may be close in a stable distribution, but they can diverge sharply when there are occasional spikes. If the tool does not calculate percentiles, export the individual observations and calculate them separately. Do not label the reported average as “average (p50).”
That small distinction changes the diagnosis. A mean pulled upward by several large spikes can hide a normal median. A median that looks comfortable can conceal a tail that is unacceptable for a strategy reacting to fast price changes. Both should be reported, along with the number of samples and the conditions under which they were collected.
A practical comparison table
There is no universal latency threshold that turns one setup into a viable scalping environment. The instrument, strategy, order type, broker, and data path all matter. Still, a broad classification can make comparisons easier:
| Observed pattern | What it suggests | Next question |
|---|---|---|
| Low median with a narrow spread | Transport is relatively stable during the sample | Does the platform render updates at the same pace? |
| Low median with occasional large spikes | The typical route is acceptable but the tail is unstable | Do spikes coincide with Wi-Fi, CPU, feed, or provider events? |
| Higher but stable latency | The route may be consistent but physically or operationally distant | Does the strategy have enough time and price tolerance? |
| Rising delay during active sessions | Congestion or processing pressure may be involved | Is the problem external, local, or specific to the feed? |
| PsPing is stable while the DOM lags | The bottleneck is probably not basic TCP transit | Inspect platform queues, CPU, memory, rendering, and feed statistics |
This is more useful than declaring a fixed number “ideal” for every trader. A manual trader placing less frequent market orders has a different tolerance from a scalper trying to react to a single level in the book. Even within scalping, a stable route with transparent slippage may be easier to manage than a faster route with unpredictable spikes.
A TCP probe can tell you whether a transport path is responding consistently. It cannot tell you where you will be filled, how much queue position you will lose, or whether the DOM is rendering every update in time.
Step 3: Interpreting Tail Latency and Jitter for Scalping Performance
Latency distributions are usually more informative than one headline average. The center describes the common case; the tail describes the conditions that can disrupt a trade at the worst moment.
Percentiles are not order statistics
The p50, or median, is the value at the center of a sorted sample. Half of the TCP observations are at or below it, and half are at or above it. It is not the arithmetic mean.
The p95 is the value below which approximately 95% of the measured probes fall. The remaining observations are slower than that level. The p99 describes the corresponding far tail.
Those statements apply to the PsPing sample. They do not automatically apply to orders. A p95 TCP result does not prove that 5% of orders received a matching delay. Orders may use another connection, be sent only during a different market state, encounter server-side queues, or be affected by exchange and broker processing that the probe never measured.
To discuss order-level latency, you need order and acknowledgment timestamps from the trading platform, broker, or execution venue. Even then, define the interval carefully. “Order latency” might mean time from click to broker receipt, submission to exchange, acknowledgment to the platform, or click to fill. These are not the same measurement.
Jitter is a distribution problem
Jitter is often used loosely to describe variation between successive observations. Standard deviation is one way to quantify dispersion, but it does not tell the whole story. Two samples can have the same standard deviation while one contains frequent moderate variation and the other contains mostly stable results with a few severe spikes.
For scalping, inspect at least:
- median latency;
- arithmetic mean;
- p95 and p99, calculated from the raw sample;
- maximum and the timestamp of the largest spikes;
- packet loss, timeouts, or failed connection attempts;
- whether the distribution changes when the platform is processing heavy market-data traffic.
A useful comparison is not “which provider has the lowest average?” but “which provider remains predictable when the strategy is active?” If one route has a slightly slower median but a much tighter tail, it may be easier to trade than a faster route that periodically pauses.
Cold and warm connections
A fresh TCP connection can behave differently from a persistent session. A cold connection may involve DNS resolution, TCP setup, TLS negotiation, authentication, and subscription messages. A warm platform session may reuse a persistent connection and avoid most of those steps.
PsPing can help reveal the transport component of a reconnect, but it does not reproduce every application-layer step. Treat a cold-start result as a diagnostic observation rather than a direct forecast of the first order after a restart.
The distinction still matters operationally. Platform restarts, dropped connections, session expiration, firewall changes, and provider failover can all move the system from a warm state to a recovery state. During recovery, the data feed may be incomplete or delayed even if the TCP port becomes reachable quickly.
Record both states when testing:
| State | What to observe |
|---|---|
| Warm session | Stability while the platform is connected and receiving normal traffic |
| Reconnect | Time to restore the session, resubscribe, and show current data |
| Post-reconnect | Whether the feed catches up cleanly or remains delayed |
| Order path after reconnect | Whether order entry is enabled, rejected, or routed through a separate session |
Test the hours you actually trade
A quiet test can make a fragile route look reliable. Repeat the measurement during the session in which the strategy operates, and compare it with a quieter period. The goal is not to force a dramatic market event; it is to see whether the route, machine, and platform remain stable when message volume and local processing increase.
During the test, watch for:
- CPU saturation on the platform's main process;
- memory pressure or paging;
- unusually high disk activity;
- chart or heatmap rendering delays;
- feed disconnects and resubscriptions;
- changes in the platform's own diagnostics;
- local network use from backups, streaming, updates, or other devices.
Market-moving events can expose weaknesses that remain invisible during routine conditions. They can also change order-book behavior and liquidity independently of network latency. Do not use a market narrative to explain a latency result unless you have a source and a measurable connection between the event and the observed infrastructure. A price move, a thinner book, and a slower platform may occur at the same time without one proving the cause of the others.
Optimizing Platform Infrastructure: RAM and Multithreading Tweaks
A latency test is valuable only if it leads to a better diagnosis. If PsPing is stable but the chart or DOM is visibly behind, the next suspect is local processing rather than the basic route to the endpoint.
Separate network delay from platform delay
The most useful comparison is between an external transport measurement and the platform's own timestamps or status indicators. For example, stable TCP results combined with rising CPU usage and delayed rendering point toward a local bottleneck. Conversely, a clean local system combined with transport spikes and reconnects points toward the network path or provider.
This is not a perfect separation. A platform may buffer, aggregate, or throttle updates, and the provider may expose only partial diagnostics. Still, comparing independent signals is better than assigning every delay to the network.
Bookmap and other depth-heavy platforms
Depth visualization can be demanding because the platform is processing a continuous stream while also maintaining historical data, heatmap state, indicators, and screen rendering. Allocate enough memory for the workspace and instrument history, but do not treat a larger allocation as a substitute for available physical RAM. If the operating system starts paging, more allocated memory can make the configuration less stable rather than more responsive.
Where the platform offers multithreaded storage or processing options, test them against the actual workspace. A setting that helps one chart layout may provide little benefit to another. Change one setting at a time, replay the same workload, and compare CPU utilization, rendering delay, and feed continuity. Vendor recommendations are a starting point, not a measured result for every machine.
Sierra Chart and similar platforms
Diagnostic servers can help establish a network baseline, especially when the platform provides separate information about data services and chart processing. Use the result to isolate components, not to claim that the diagnostic endpoint exactly reproduces a production feed.
Background loading and rendering options can also matter. If loading historical data or recalculating a chart competes with live updates, the visible chart may lag even though packets are arriving on time. Keep the workspace focused during testing and avoid comparing a minimal chart with a fully loaded multi-chart layout.
Reduce avoidable local variation
A few infrastructure choices are simple and measurable:
1. Use a wired connection when possible. Wi-Fi can introduce variation from interference, roaming, power management, and competing devices. Ethernet does not make the remote route faster, but it removes one local source of jitter.
2. Keep the trading machine free of unnecessary background load during the session. Browser tabs, cloud synchronization, updates, recording tools, and streaming applications can compete for CPU, memory, disk, or bandwidth.
3. Watch the process rather than the whole computer. Overall CPU usage can look moderate while one platform thread is saturated.
4. Disable power-saving behavior that throttles the processor or network adapter at the wrong time, then verify that temperatures remain under control.
5. Keep the data and order paths separate in your notes. A faster market-data connection does not prove that order entry uses the same endpoint or route.
6. Test the exact configuration used for live trading. A VPS, home workstation, remote desktop session, and backup laptop are different environments even when they run the same platform.
Location can matter because routing distance and provider peering affect transport time, but geography alone is not a guarantee. A server in the same broad region can use a poor route; a more distant server can have better peering to a particular vendor. Compare measured results from candidate locations instead of relying on monthly price, city labels, or assumptions about where a matching engine sits.
From a Ping Test to an Execution Test
The three-step test gives you a transport profile:
- which endpoints are active;
- how the TCP path behaves over time;
- how much variation appears in the center and the tail of the sample.
That profile is useful for finding obvious problems. It can reveal a noisy Wi-Fi link, an unstable VPS route, intermittent timeouts, or a large difference between quiet and active periods. It can also show that the network is not the limiting factor, directing attention toward platform rendering, data-feed handling, or machine resources.
It cannot establish the complete latency of a fill. For that, collect the most detailed timestamps your platform and broker provide. Compare order submission, broker acknowledgment, exchange acknowledgment, cancellation, and execution reports when those fields are available. Keep the order type, instrument, session state, and market conditions with the record. A market order, passive limit order, cancel request, and data subscription are different events and should not be collapsed into one number.
The same discipline applies to backtesting. A strategy may appear profitable with historical data while having no tolerance for reconnects, queueing, or stale displayed depth. The answer is not to choose the lowest ping and assume the edge is protected. It is to identify which part of the path the strategy depends on and measure that part as directly as the platform allows.
Latency is a cost of the live environment, but it is not a fixed fee that can be read from one command. The useful number is a distribution attached to a specific path, endpoint, platform, and trading condition. Start with TCPView, test with PsPing, inspect the tail, and then verify the result against actual platform and order records. That is enough to replace a misleading ICMP baseline with a working infrastructure diagnosis.