forex-scalping.com

Classic scalper argument: "Just get a London VPS" vs "Just pick the broker with LD4/NY4 matching." Reality is messier.

I care about **path**, not marketing city names.

What I measure:
1. VPS → broker gateway ping (ICMP is a hint, not gospel)
2. Order round-trip on a micro market order off-hours vs into London open
3. Whether the broker's "London server" is actually where your account is booked (ask support; answers vary from precise to poetic)

Things I've learned the hard way:
- A "London VPS" routed poorly can lose to a Frankfurt box with a clean path.
- Moving VPS closer helped less than switching account type / liquidity route on one broker.
- Windows timer + MT5 terminal overhead can dominate your fancy 0.3ms ping fantasy. Ping isn't fill.

Also: if you run Python signal → MT5 order, your bottleneck might be your own script, not Equinix. Ask me how I know.

For London-session FX scalps, what's your current VPS location + broker server combo?
Have you A/B tested two VPS cities with the *same* broker and same lot size?
Anyone running cTrader Open API / FIX and still using a consumer VPS, or did you outgrow that?

Hi,

thank you for this post, you are right
I found it out too but in hard way.

What VPS or Google cloud instance do you prefere?

Btw this is why big companies have coolocated their cluster in the same building or building next and invest hundreds of milions of $ to be there with orders first.

Path over city branding

“London VPS” on a sales page is not a latency strategy. I care about path: where the terminal runs, where the broker matches, and what round-trip looks like on my orders under session load.

From Frankfurt I measure:

• Terminal to broker gateway round-trip under open load, not only idle ping screenshots.
• Slippage and rejects at the open versus midday on the same pair.
• Whether moving VPS region actually changed deal quality in the log over a fair sample.

Sometimes broker matching location wins; sometimes a closer VPS helps; sometimes neither fixes a wide book. The sheet decides, not the marketing city name. Full-time scalping rewards measurement more than folklore.

Document the test window in advance: same pair, same session, minimum deal count before you declare a winner. Otherwise you will crown a VPS after twelve lucky fills and call it science.

Did a VPS move ever improve your tails meaningfully on the same broker, or did broker choice dominate the result?

I ran the same broker test LondonScalper asked about last spring, mostly to settle an argument with myself. Same account, same 0.1 lot on EURUSD, one terminal in London and one in Amsterdam, about 300 market orders each spread over three weeks of opens.

The London box had a median round trip near 4 ms against roughly 11 ms from Amsterdam. Average slippage from 08:00 to 08:30 differed by about 0.05 pip, which was smaller than the week to week swing on either box.

What did move the numbers was rejects. One week the broker had a run of requotes on both terminals at once, so the cause sat on their side and no VPS move would have fixed it.

PTScalper, I would not choose by brand. A general cloud region in the same metro works if you size it so the terminal never fights for CPU, because a stalled terminal at the open costs far more than a few milliseconds of path.

PropScalpDesk's point about a minimum deal count is the bit most people skip. I would also compare the terminal's own send time against the execution stamp in the history, since that gap was the most honest latency number I found. Has anyone else tried that?

Comparing the terminal send time with the execution stamp only works if both clocks agree, and that caught me out. My VPS had drifted about 40 ms against the broker server within a week, which was larger than the path difference I was trying to measure.

Running a time sync service every few minutes fixed it, but I still treat any gap under 10 ms as noise. A difference has to show up as a median over a few hundred orders before I believe it.

On LondonScalper's point about Python being the bottleneck, I measured mine with timestamps at the signal, at the order call and at the terminal's own log line. The call itself was quick, but polling for new ticks every 100 ms meant the average signal sat around 50 ms before anything was sent.

Moving to an event driven tick handler cut that to a few milliseconds and did more than either VPS move would have. It is the cheapest latency fix most retail setups have, and nobody sells it.

PropScalpDesk, did your slippage at the open change at all after a VPS move, or did it sit inside the weekly noise like mine? I suspect most of the tails people blame on distance come from the broker's last look rather than the cable.

Behind a retail platform sits a piece of software that decides how orders meet prices. Some brokers run an internal matching engine that pairs client orders against each other or against the broker's own book. Others pass orders through to external liquidity pools. Many use a mix.

The distinction affects behavior at the edges. An internal engine can fill limit orders when the broker's own quote touches the level, even if the wider market has not traded there. A pass-through model fills only when an external provider actually trades at that price, which can lead to missed fills at exact touches.

Scalpers placing limit orders to capture spread should find out whether a touch is enough or whether price must trade through the level. Test with small sizes and compare fill rates against the chart. Differences between expected and actual fills offer clues about the underlying engine, and those clues feed directly into how limit-based entries should be sized and positioned.

PTScalper, the colocation point puts the VPS question in perspective: the big players solve latency with buildings, so retail traders only need to avoid being unnecessarily far away. A simple way to choose a location is to measure the ping from each candidate to the broker's trade server and compare the actual execution time in the journal before and after a move.