Latency is the tax.
Jitter is the robbery.
One you survive. The other kills strategies.
Most traders blame their broker when fills go wrong. Some blame the spread. A few blame the signal. Almost none look at the path their order packet takes to get there — or what happens to that path during the moments it matters most.
This guide explains the difference between latency and jitter, shows you how to measure both, and explains what actually fixes the one that costs you the most.
Latency is the baseline round-trip time from your machine to your broker's server — a fixed cost you can plan around. Jitter is the variance in that round-trip time — the gap between your fastest and slowest packet. Jitter matters more for traders because it is unpredictable: a consistent 40 ms path is tradeable, but a path that swings between 40 ms and 160 ms during news events breaks fills, triggers stops wide, and causes limit orders to miss entirely. Most retail traders have a jitter problem, not a latency problem — and most common fixes (faster broadband, consumer VPS) solve latency without touching jitter.
The simplest true definitions.
Two numbers live inside every trading session. Most traders never see either of them.
Latency is the time it takes your order packet to travel from your machine to your broker's matching engine and back. A round trip. Measured in milliseconds. If you ping your broker's server and the result says 42 ms, that is your latency.
Jitter (the wobble in your fill time) is how much that number moves from packet to packet. If one ping takes 42 ms, the next takes 38 ms, the next takes 91 ms, and the next takes 45 ms — your average is somewhere around 54 ms, but your jitter is enormous. The spread between your best and worst packet is what jitter measures.
The commute analogy is the clearest:
Consistent latency: your office is 30 minutes away. Every day. Rain or shine. Monday to Friday. You plan around 30 minutes. You leave at 8:00 and arrive at 8:30. No surprises.
High jitter: your office is 30 minutes away on a good day. But sometimes traffic makes it 90 minutes. Sometimes 45. You never know which. You can't plan. You leave early every day to cover the worst case, and you still miss meetings.
That is the difference. Latency is the baseline travel time. Jitter is the variance around that baseline. Both matter. But they matter differently. And they have entirely different causes.
| Latency | Jitter | |
|---|---|---|
| What it measures | Baseline round-trip time | Variance in round-trip time |
| Unit | Milliseconds (average) | Milliseconds (spread) |
| How consistent | Relatively stable | Unpredictable by definition |
| Primary cause | Physical distance + routing hops | Congestion, reordering, retransmission |
| Can you plan around it | Yes | No |
| The trader's metaphor | A tax on every trade | A robbery at random moments |
Keep both definitions in mind as you read. They explain very different problems.
Why jitter hurts more than latency.
Latency is a constant you can factor in. A consistent 40 ms round-trip is a known cost. Your backtest accounts for it, because your backtest was built on data that already reflects a certain execution reality. You place a trade at price X and you get filled at price X — or something very close to it — every time. The 40 ms is baked in.
Jitter is random theft. It strikes at moments you can't predict, in amounts you can't anticipate. Your backtest assumed consistent execution. Live trading with high jitter delivers inconsistent execution. The gap between those two is where strategies bleed.
Here are three ways jitter costs traders that latency alone does not.
Scalping a tight target
You're scalping a 5-pip target with a 3-pip stop. Your entry fires at the right price. On a low-jitter path, your order arrives at the broker in roughly the same time as it always does. The broker fills you near the price you saw.
On a high-jitter path, your order packet takes twice as long as usual to arrive. The price moved. The broker fills you at a worse price — or re-quotes you. Your 5-pip target just became a 2-pip target after spread. Your risk/reward broke before you held the trade for a second.
Limit orders not filling
You set a limit order at a price that was touched — you can see it on the chart. The broker says no fill. The price moved through your level and back before your order packet arrived. Your jitter spike ate the fill.
This is a misunderstood source of "broker manipulation" complaints. Many of them are actually jitter events. The broker's server never received your order in time. The broker did not manipulate anything. Your path did.
Stops triggering wide during news
You have a stop at a specific level. During NFP, your stop triggers 8 pips beyond where you set it. You expected 3 pips of slippage. You got 8.
Here is what happened: the news event caused a congestion spike on your path. Your broker received your stop-trigger acknowledgement late — and by the time it processed, the market had moved further. Jitter converted a manageable stop into a trade you would not have taken at that risk level.
"A consistent 40 ms is a tax you can pay. A 40 ms path that spikes to 200 ms during news is a trap you can't price."
Latency is a cost you absorb into your trading model. Jitter is a random variable you cannot model. That is why traders who understand this obsess over jitter more than they obsess over raw speed.
Where latency actually comes from.
Your order packet does not teleport to your broker's server. It travels a physical chain. Every link in that chain adds time.
network stack
WiFi overhead
peering point
transit hops
order processing
Every arrow adds time. Physical constraints cap the minimum. Routing quality determines how close to that minimum you actually get.
The speed of light is a ceiling, not a floor
Light travels through fibre at roughly two-thirds the speed of light in a vacuum — about 200,000 km per second in the cable. London to New York is about 5,500 km. The physics minimum is around 28 ms one way, 56 ms round trip.
Real-world London-New York paths typically show 70"“85 ms. That gap between 56 ms and 80 ms is routing overhead: extra hops, suboptimal backbone paths, peering arrangements that route traffic through an intermediate city before it goes where it's going.
If your broker's server is in New York and you're trading from London, your hard floor is roughly 56 ms round trip. No amount of money or technology moves that. What you can control is how close to the floor your actual path runs.
The hidden routing problem
Your ISP's job is to deliver traffic to the internet, not to deliver trading traffic to your broker's specific data centre with minimum hops. Your packets follow the cheapest route your ISP negotiated at its peering exchanges — not the fastest one to your broker's location.
This means two traders in the same city, on different ISPs, connecting to the same broker, can have dramatically different latency profiles. One ISP peers directly with the carrier that serves that broker's data centre. The other ISP routes via a hub in a different country first.
Most traders have no way to know which situation they're in. Running a traceroute (covered in Chapter 05) shows you the path your packets actually take.
(approximate)
between you and broker
per unnecessary hop
Where jitter actually comes from.
Jitter is not random chaos. It has specific causes. Each one is worth understanding — because each one is addressable in a different way.
1. Queueing delay at your ISP during peak hours
Your ISP's local equipment handles traffic from every subscriber in your area. At 8pm on a weeknight — or during a major news event when every trader on the same exchange fires orders at the same moment — that queue builds up. Your 200-byte order packet sits behind a 1.4 MB video stream fragment waiting its turn. The video fragment goes first. Your packet waits 30 ms. Then it goes.
This is called bufferbloat. It is the most common source of jitter on consumer broadband. It is worst on cable connections (DOCSIS) and on ISPs that use aggressive traffic shaping. It gets dramatically worse during news events.
2. Multi-path routing and packet reordering
Some backbone networks split large TCP flows across multiple physical paths to balance load. If your session traverses a path where packets take different routes — one packet goes via Chicago, the next via Atlanta — they arrive out of order. TCP reassembles them. But the reassembly wait adds time. And that time is not consistent.
3. Retransmissions from packet loss
If a packet is lost in transit, TCP detects it (via acknowledgement timeout) and sends it again. That retransmission adds the full round-trip time to the delivery of the data that was in the lost packet. For a trading session, a single retransmission during order submission can add one full RTT of delay at exactly the wrong moment.
Packet loss is higher than most traders expect on long-haul consumer paths. A path with 0.1% packet loss sounds negligible. Run it for 1,000 packets — which a busy MT4 session can do in minutes — and you have 1 dropped packet with a forced retransmission.
4. CPU scheduling on your machine and on the relay
Your operating system's kernel decides when to forward your outgoing packet to the network card. On a busy machine — one with a background Windows Update running, or an antivirus scan, or a Chrome tab indexing a page — your packet can sit in the kernel queue for several milliseconds before the CPU cycle that flushes it to the wire. You feel this as occasional single-packet spikes in your ping data.
On a proxy or relay node, the same problem exists. If the relay's kernel is not tuned for low-latency TCP forwarding — if it treats all traffic as equal priority — your order packet waits behind bulk data.
The four jitter sources in order of how fixable they are:
- CPU scheduling on your machine — fix with a dedicated low-load trading setup
- Last-mile bufferbloat — partially fix with QoS settings on your router
- Multi-path reordering — fix by choosing a relay that uses a single deterministic path
- ISP queueing during peak/news — the hardest to fix without a network-level solution
How to measure your own latency and jitter.
You don't need special software. You need three free tools and 20 minutes. The goal is to build a picture of your trading network path — baseline, variance, and where the problem lives.
- Find your broker's server address
In MT4: go to File ← ’ Open an Account. Look at the server dropdown. The address shown (e.g.
demo.broker.comor an IP like185.56.xxx.xxx) is what you'll ping. In MT5: Tools ← ’ Options ← ’ Server tab. Write the address down. - Run a sustained ping — not just 4 packets
Open a terminal (Command Prompt on Windows, Terminal on Mac/Linux). Run:
ping -n 100 [your broker server address]On Mac/Linux, use
ping -c 100instead. Let 100 packets complete. Look at the summary line — minimum, maximum, and average. The gap between minimum and maximum is your jitter range on a quiet day. - Trace the path with tracert or mtr
On Windows:
tracert [your broker server address]On macOS/Linux, install and run
mtr— it combines traceroute and ping into one live view. Each line is one network hop. Look for hops where the latency jumps sharply — that is where delay is being added. Look for hops with high variability — that is a jitter source. - Check the MT4/MT5 built-in server ping
In MT4: View ← ’ Terminal ← ’ Trade tab. The ping column at the bottom right shows your round-trip to the broker's server in milliseconds. This is a live reading, not a one-shot test. Watch it for several minutes. A good number stays consistent. A bad number bounces.
In MT5: the connection indicator in the bottom-right corner of the chart shows server latency. Click it for the current ping value.
- Run the same tests during a news event
A quiet Tuesday at 9am UTC is your baseline. NFP Friday at 13:30 UTC, or FOMC announcement time, is the stress test. Your baseline tells you your normal path quality. The stress test tells you how your path behaves when it matters most. The difference between the two is the number that shapes your actual trading risk.
Reading the numbers
| Scenario | Latency (avg) | Jitter (min-max spread) | Verdict |
|---|---|---|---|
| Co-located VPS, same DC as broker | <5 ms | <1 ms | Institutional standard |
| Good residential path, same country | 15"“40 ms | 3"“8 ms | Workable for most retail |
| Consumer broadband, peak hours | 40"“80 ms | 20"“60 ms | Jitter is the problem |
| Long-haul path (cross-continent) | 80"“200 ms | 10"“40 ms | Latency is the problem |
| Mobile / 4G, during news | 50"“150 ms | 30"“100+ ms | Both are problems |
The right question is not "is my latency good?" It is: "what is the worst-case spike I'll see during a news event?" Your worst case is your real execution risk.
Why a VPS doesn't fix jitter (unless it's co-located).
A VPS near the broker fixes latency. That part is true. If your broker's server is in London and you buy a VPS in London, your round-trip from the VPS to the broker might be 2"“5 ms instead of 80 ms from your home in Singapore. The latency problem goes away.
The jitter problem moves. It does not go away.
Here is why. A VPS is a virtual machine running on shared physical hardware in a data centre. That data centre has its own network path — its own upstream providers, its own peering arrangements, its own congestion patterns. If the VPS host's network is not tuned for low-latency TCP forwarding — and most consumer VPS hosts are not — your order traffic shares a pipe with other tenants on that host running bulk workloads, backups, and data transfers.
You traded your home internet jitter for data-centre jitter. The numbers might be better. The problem structure is the same.
Co-location solves this. A co-located server sits in the same physical facility as the broker's matching engine, on dedicated hardware, on a network that the broker's data centre provider specifically tunes for low-latency financial traffic. The path from your server to the broker's server is measured in metres of fibre, not kilometres of backbone.
Most retail traders cannot buy co-location. The minimum contract is typically several hundred dollars a month and requires technical management. That is the institutional-only gap this product was built to address.
Retail traders pay for two layers. Professionals pay for three.
Layer 1 is the platform — MT4, MT5, cTrader. Free from your broker. Layer 2 is the idea — signals, courses, EAs. You've spent money here. Layer 3 is the network path every order packet travels. Professionals pay for this as a line item. Retail traders spend $0 on it — not because it's free, but because nobody named it.
The gap between a standard VPS and a properly-tuned network relay is not just latency. It is the difference between solving one half of the problem and solving the whole thing. Read the full letter ← ’
How TradersProxy handles both.
Every technical claim below traces to a specific specific proof point in the product. The values are not published — that is deliberate — but the behaviour is real and verifiable.
Congestion algorithm chosen per connection
Standard consumer TCP stacks use a single congestion algorithm for all traffic — usually CUBIC, which is optimised for high bandwidth, not for low latency. TradersProxy selects the appropriate congestion algorithm at the point each connection is established, based on the connection's characteristics. This means an order submission connection gets algorithm choices that minimise round-trip time, not ones that maximise throughput.
Split TCP buffers — interactive vs bulk
Not all traffic through the relay is a 200-byte order packet. Some is tick data. Some is chart history. Treating them identically means your order packet waits behind a large tick download to get through the relay's output buffer. The node configuration splits these into separate buffer pools. Order flow gets a buffer optimised for short, time-sensitive packets. Bulk data gets a buffer optimised for throughput. They do not compete.
Priority ports for order flow
The platform sends different types of traffic on different ports. The relay identifies which port carries order-submission traffic and assigns it to the high-priority queue in the kernel's traffic shaper. Your order packet goes to the front of the queue. It does not wait.
News-spike jitter absorption
News events cause a burst of outbound traffic — every trader on the node fires orders at the same second. Without a jitter-absorption mechanism, that burst builds a queue and every order packet waits longer. The node config includes a dedicated burst-smoothing parameter that absorbs the peak and releases packets in a controlled sequence rather than a spike-and-drain pattern.
Route-quality monitoring with a 15-minute window
The relay does not assume the path to the broker stays good. It measures it on an ongoing basis using an exponentially weighted moving average over a 15-minute window. When path quality degrades — latency climbs, packet loss appears — the routing logic can shift connections to a better-performing node. You don't see this. Your session stays alive.
3-band priority queue at the kernel level
The Linux traffic shaper on each node runs a 3-band HTB (Hierarchical Token Bucket) queue. Order-flow traffic is in band 1 — maximum priority. Interactive traffic is band 2. Bulk traffic is band 3. Even on a loaded node, your order packet does not get stranded behind a 1 MB chunk of tick data.
HTB burst pool scaled for news events vs normal traffic
The traffic shaper's burst allowance — the amount of extra bandwidth available for short peaks — is configured separately for news-event periods vs normal market hours. During news, the burst pool expands. The queue has more headroom to absorb spikes without forcing packets to wait.
The FOMC test.
Pick any FOMC announcement day. The decision drops at 19:00 UTC. For ten seconds before and thirty seconds after, every trader watching that event fires orders at the same moment.
On default infrastructure, here is what that looks like at the network level. Your ISP's local equipment is handling a surge. Dozens of traders in your area — many on consumer broadband sharing the same exchange point — are sending traffic simultaneously. Your ISP's queue builds. Packets wait. Your ping to your broker's server, which was 45 ms at 18:59, is now 160 ms at 19:00:03. Your stop runs 12 pips instead of 4. Your limit order that should have filled on the first touch does not fill at all — the confirmation packet arrived after the price moved.
You close the trade. You run the post-mortem. The price touched your target. The platform's history confirms it. But there was no fill. You chalk it up to broker requotes. You move on.
On a path with jitter absorption, the same moment looks different. The burst hits the relay. The node's HTB burst pool expands to accommodate the volume. The jitter-absorption parameter smooths the output queue rather than letting it spike and drain chaotically. Your order packet is in the priority band. It does not wait for bulk traffic. It goes to the front.
What "jitter absorption" means in plain English: instead of your order queue spiking from 45 ms to 160 ms during the announcement, it might move from 45 ms to 60 ms. The burst is absorbed. The spike is smoothed. Your order arrives at the broker while the price is still close to where you saw it.
This is not magic. It is engineering applied to a specific problem. The FOMC announcement is the stress test that exposes paths that are not built for this. A path that shows 3 ms of jitter on a quiet Tuesday can show 80 ms during FOMC. A path designed for news events shows far less variance because the variance was anticipated and accounted for in the design.
That is the structural difference between a network relay tuned for trading and a generic VPS rental.
Three things that don't work the way you think.
Most trading network advice online is written by people who understand bandwidth. Bandwidth is not what trading needs. These three myths come from confusing bandwidth with latency and jitter.
"My speed test shows 200 Mbps. My connection is fine."
Speed tests measure how much data fits through your pipe per second. An order packet is 200 bytes. Your 200 Mbps connection can send thousands of those per second. Bandwidth is not the constraint.
Speed tests tell you nothing about latency and nothing about jitter. A 200 Mbps connection can have 80 ms of jitter during peak hours. That jitter will affect fills. The speed test will still say 200 Mbps.
"Fibre is always faster than 4G for trading."
Fibre is better for bandwidth and stability. For raw latency on a long-distance path, what matters is routing — not the last-mile technology. A 4G connection with good carrier routing and a direct peering arrangement to your broker's data centre can have lower latency than a fibre connection that routes via a suboptimal path.
Fibre is generally more stable. But stability ←°, and speed ←° Run a traceroute on both and compare actual hop counts and per-hop latency. The test tells the story. The technology label doesn't.
"5G will solve my trading latency."
5G reduces the wireless hop latency from tower to phone — from around 30"“50 ms on 4G to around 5"“10 ms on a good 5G signal. That matters if the wireless hop is your bottleneck. On most long-distance trading paths, the wireless hop is a small fraction of total latency. The bottleneck is the backbone routing between your country and your broker's data centre.
A good 4G path with well-engineered backbone routing beats a 5G path with poor backbone routing every time. Measure your full path with traceroute. The bottleneck is almost never the last wireless hop.
Eight questions worth answering.
Under 50 ms is workable for most retail discretionary trading. Under 20 ms is good for scalping. The number matters less than the consistency. A stable 40 ms is better than an average of 25 ms with spikes to 120 ms. Watch the MT4 ping display for several minutes — not just a single reading — to understand your real variance.
A well-tuned path shows jitter under 5 ms. Consumer broadband in a residential area typically shows 10"“30 ms of jitter under normal conditions and considerably more during peak hours or news events. If your ping's min-to-max spread is over 20 ms on a quiet day, your path has a jitter problem.
No. Fibre is generally better for stability and bandwidth. For raw latency on a long-distance path, routing quality matters more than last-mile technology. A well-routed 4G signal with direct carrier peering to your broker's data centre can beat a fibre connection that routes inefficiently. Run traceroute on both connections and compare the actual hop counts and per-hop times.
Yes — they show you the baseline and the variance. Run ping for at least 60 seconds, not just 4 packets. 100 packets is better. The min/max/average spread is the signal. A large spread means jitter. A high average means latency. Both matter differently. One ping test tells you almost nothing. A 100-packet run shows your real path quality.
Speed tests measure bandwidth — how much data fits through your pipe per second. MT5 cares about latency — how fast a tiny 200-byte packet gets to the broker and back — and jitter — how consistent that speed is. A 200 Mbps connection with 40 ms of jitter performs worse for trading than a 20 Mbps connection with 3 ms of jitter. Speed tests and trading performance measure entirely different things.
It depends on your strategy and, more importantly, how stable that 50 ms is. For momentum or news-driven scalping where you're reacting to a visible move, 50 ms is workable. It starts hurting when you're targeting very tight spreads and your edge requires sub-second precision. A consistent 50 ms you can plan around. A 50 ms average that spikes to 180 ms during the moments you trade — you cannot plan around that.
Yes. Wi-Fi adds 2"“10 ms of jitter on a good day in a quiet environment. In a dense apartment building on the 2.4 GHz band with channel congestion from 20 neighbouring networks, that number can be far higher. A wired ethernet connection eliminates this jitter source entirely. If you're serious about execution quality, wired is the starting point — everything else builds on top of it.
Distance adds baseline latency that cannot be removed — the speed of light is the ceiling. What you can improve is the path quality. Consumer ISPs often route long-distance traffic inefficiently, adding hops that inflate latency beyond the physical minimum. A relay with clean peering arrangements and well-chosen backbone routes can reduce hop counts and lower your effective round-trip time even when you're geographically distant from your broker's data centre.
You know what jitter is. You know what it costs.
You've read the definitions, the causes, the measurement guide, and the FOMC scenario. The path from here is straightforward: measure your own numbers using Chapter 05, then decide whether a jitter-managed relay is the right fix.
See the plans ← ’ · Read the full technical case · Related: MT4/MT5 slippage fix · Why SOCKS5 beats VPN