Latency note for retail scalpers -- measure before you buy another VPS story.
I care about round-trip only insofar as it shows up in rejects, slippage, and missed cancels. A pretty ping number that does not change those is entertainment.
Crude measurement I trust more than marketing
1. Same order type, same symbol, same session window, for a week.
2. Log click time vs server/fill time when the platform exposes it.
3. Compare home connection vs VPS on identical checklist days -- not during a random spike.
If the VPS does not reduce my reject clusters or improve cancel reliability on partials, I do not renew it for ego. If it does, the cost goes into the pair's cost model like commission.
Also: clock sync. Measuring latency with a drifting OS clock is how you invent problems.
For those who did a proper before/after, what metric actually improved -- and what stayed the same?
How to measure round-trip latency from your VPS to the broker
-
LondonScalper
- Posts: 701
- Joined: Sat Sep 05, 2026 7:54 am
Re: How to measure round-trip latency from your VPS to the broker
Hi LondonScalper,LondonScalper wrote: Mon Sep 14, 2026 7:29 pm Latency note for retail scalpers -- measure before you buy another VPS story.
I care about round-trip only insofar as it shows up in rejects, slippage, and missed cancels. A pretty ping number that does not change those is entertainment.
Crude measurement I trust more than marketing
1. Same order type, same symbol, same session window, for a week.
2. Log click time vs server/fill time when the platform exposes it.
3. Compare home connection vs VPS on identical checklist days -- not during a random spike.
If the VPS does not reduce my reject clusters or improve cancel reliability on partials, I do not renew it for ego. If it does, the cost goes into the pair's cost model like commission.
Also: clock sync. Measuring latency with a drifting OS clock is how you invent problems.
For those who did a proper before/after, what metric actually improved -- and what stayed the same?
Your testing methodology is spot-on. Chasing a 1ms ping is pointless if the broker's internal routing takes 80ms to process the ticket. For retail scalping, treating a VPS purely as an infrastructure cost—where it must justify itself by measurably reducing slippage and reject costs—is the only logical approach.
Here is the basic breakdown of what actually changes when moving from a home connection to a VPS, and what remains exactly the same.
What Actually Improves
Execution Consistency (Variance): You might not get dramatically better fills, but you get consistent ones. A home ISP might average 30ms but occasionally spike to 250ms due to local network routing. A cross-connected VPS flattens that variance, directly reducing those random "reject clusters" during fast price action.
Cancel Reliability: This is the one area where raw ping reduction shines. Cutting 40ms off a round-trip shrinks the micro-window where the market fills a resting order right as you attempt to pull it.
Unattended Script Stability: If you are running custom automated tools, MQL/cAlgo EAs, or order rejection loggers 24/5, the VPS removes local hardware sleep cycles, forced OS updates, and home router resets from the equation.
Preserve your own money. Scale with the market's money. Exponential growth is the ultimate key.
Re: How to measure round-trip latency from your VPS to the broker
What Stays Exactly the Same
Broker-Side Processing (The Bridge Lag): A 1ms connection to the server means nothing if the broker’s dealing desk or bridge to their liquidity provider takes 100ms to confirm the fill. The platform's internal overhead (especially in older infrastructure like MT4) remains a hard bottleneck.
Liquidity Sweep Slippage: During major news prints or aggressive liquidity grabs, the order book thins out. A VPS might get your market order to the server a fraction of a second faster, but if the liquidity at your price level is already gone, you will still experience the exact same slippage.
The Strategy's Core Edge: If your 1-minute or 5-minute price action setups are flawed, a VPS simply executes losing trades faster.
Your point on clock sync is critical. Without enforcing strict NTP (Network Time Protocol) synchronization, comparing client terminal logs to server timestamps is essentially reading tea leaves. If the math after a week of identical, synchronized session logging doesn't show a reduction in execution costs that exceeds the monthly server fee, the VPS is just marketing dead weight.
Broker-Side Processing (The Bridge Lag): A 1ms connection to the server means nothing if the broker’s dealing desk or bridge to their liquidity provider takes 100ms to confirm the fill. The platform's internal overhead (especially in older infrastructure like MT4) remains a hard bottleneck.
Liquidity Sweep Slippage: During major news prints or aggressive liquidity grabs, the order book thins out. A VPS might get your market order to the server a fraction of a second faster, but if the liquidity at your price level is already gone, you will still experience the exact same slippage.
The Strategy's Core Edge: If your 1-minute or 5-minute price action setups are flawed, a VPS simply executes losing trades faster.
Your point on clock sync is critical. Without enforcing strict NTP (Network Time Protocol) synchronization, comparing client terminal logs to server timestamps is essentially reading tea leaves. If the math after a week of identical, synchronized session logging doesn't show a reduction in execution costs that exceeds the monthly server fee, the VPS is just marketing dead weight.
Preserve your own money. Scale with the market's money. Exponential growth is the ultimate key.
Re: How to measure round-trip latency from your VPS to the broker
This MQL5 script fires a minimal market order, measures the exact microsecond round-trip using GetMicrosecondCount(), calculates the exact slippage in points, and appends the results to a CSV file.
You can drop this logic into an EA's OnTimer to automate sampling during identical session windows on both your home connection and the VPS.
Execution & Slippage Logger (MQL5)
You can drop this logic into an EA's OnTimer to automate sampling during identical session windows on both your home connection and the VPS.
Execution & Slippage Logger (MQL5)
Code: Select all
//+------------------------------------------------------------------+
//| ExecutionBenchmark.mq5 |
//+------------------------------------------------------------------+
#property strict
#property script_show_inputs
input double InpLotSize = 0.01; // Test Lot Size
input ulong InpMagic = 999111; // Magic Number
void OnStart()
{
MqlTradeRequest request={0};
MqlTradeResult result={0};
request.action = TRADE_ACTION_DEAL;
request.symbol = _Symbol;
request.volume = InpLotSize;
request.type = ORDER_TYPE_BUY;
request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
request.deviation= 50; // High deviation to ensure fill and capture true slippage
request.magic = InpMagic;
request.type_filling = ORDER_FILLING_FOK;
Print("Sending benchmark order...");
// Measure microsecond round-trip latency
ulong startTime = GetMicrosecondCount();
bool success = OrderSend(request, result);
ulong endTime = GetMicrosecondCount();
double latencyMs = (endTime - startTime) / 1000.0;
double slippagePts = 0;
if(success && result.deal > 0)
{
// Calculate slippage: (Requested Price - Actual Fill Price) converted to points
slippagePts = MathAbs(request.price - result.price) / _Point;
PrintFormat("Execution: %.2f ms | Slippage: %.1f pts | Retcode: %d", latencyMs, slippagePts, result.retcode);
}
else
{
PrintFormat("Rejected: %.2f ms | Retcode: %d", latencyMs, result.retcode);
}
// Append to CSV in Terminal\MQL5\Files
int fileHandle = FileOpen("Execution_Benchmark.csv", FILE_CSV|FILE_WRITE|FILE_READ|FILE_ANSI, ',');
if(fileHandle != INVALID_HANDLE)
{
FileSeek(fileHandle, 0, SEEK_END);
if(FileSize(fileHandle) == 0) // Write headers if new file
{
FileWrite(fileHandle, "Time,Symbol,Type,ReqPrice,FillPrice,SlippagePts,LatencyMS,RetCode");
}
FileWrite(fileHandle, TimeToString(TimeCurrent(), TIME_DATE|TIME_SECONDS), _Symbol, "BUY",
DoubleToString(request.price, _Digits), DoubleToString(result.price, _Digits),
DoubleToString(slippagePts, 1), DoubleToString(latencyMs, 2), IntegerToString(result.retcode));
FileClose(fileHandle);
}
}Preserve your own money. Scale with the market's money. Exponential growth is the ultimate key.
Re: How to measure round-trip latency from your VPS to the broker
Windows OS Clock Sync
Before running the test on either machine, force a strict NTP sync to prevent timestamp drift from muddying your log comparisons. Run this in PowerShell as Administrator:
To run a clean comparison:
1.) Run the script on your home setup during your chosen session window.
2.) Next week, run it on the VPS during the exact same session window and market conditions.
3.) Pull both Execution_Benchmark.csv files and compare the LatencyMS variance and RetCode (reject) frequency.
Before running the test on either machine, force a strict NTP sync to prevent timestamp drift from muddying your log comparisons. Run this in PowerShell as Administrator:
Code: Select all
# Force immediate hardware-to-NTP clock sync
w32tm /resync /force
# Verify the offset and synchronization source
w32tm /query /status1.) Run the script on your home setup during your chosen session window.
2.) Next week, run it on the VPS during the exact same session window and market conditions.
3.) Pull both Execution_Benchmark.csv files and compare the LatencyMS variance and RetCode (reject) frequency.
Preserve your own money. Scale with the market's money. Exponential growth is the ultimate key.
Re: How to measure round-trip latency from your VPS to the broker
MQL4 version 1.0
Code: Select all
//+------------------------------------------------------------------+
//| ExecutionBenchmark.mq4 |
//+------------------------------------------------------------------+
#property strict
#property show_inputs
extern double InpLotSize = 0.01; // Test Lot Size
extern int InpMagic = 999111; // Magic Number
void OnStart()
{
// Refresh rates to ensure we have the latest Ask price
RefreshRates();
double reqPrice = Ask;
int slippageTolerance = 50; // High tolerance to ensure fill and measure true slippage
Print("Sending benchmark order...");
// Measure microsecond round-trip latency
ulong startTime = GetMicrosecondCount();
int ticket = OrderSend(Symbol(), OP_BUY, InpLotSize, reqPrice, slippageTolerance, 0, 0, "Benchmark", InpMagic, 0, clrGreen);
ulong endTime = GetMicrosecondCount();
double latencyMs = (endTime - startTime) / 1000.0;
double slippagePts = 0;
double fillPrice = 0;
int errCode = 0;
if(ticket > 0)
{
// In MQL4, you must select the ticket to retrieve the actual fill price
if(OrderSelect(ticket, SELECT_BY_TICKET))
{
fillPrice = OrderOpenPrice();
// Calculate slippage: (Requested Price - Actual Fill Price) in points
slippagePts = MathAbs(reqPrice - fillPrice) / Point;
PrintFormat("Execution: %.2f ms | Slippage: %.1f pts", latencyMs, slippagePts);
}
}
else
{
errCode = GetLastError();
PrintFormat("Rejected: %.2f ms | Error code: %d", latencyMs, errCode);
}
// Append to CSV in Terminal\MQL4\Files
int fileHandle = FileOpen("Execution_Benchmark_MQL4.csv", FILE_CSV|FILE_WRITE|FILE_READ|FILE_ANSI, ',');
if(fileHandle != INVALID_HANDLE)
{
FileSeek(fileHandle, 0, SEEK_END);
if(FileSize(fileHandle) == 0) // Write headers if new file
{
FileWrite(fileHandle, "Time,Symbol,Type,ReqPrice,FillPrice,SlippagePts,LatencyMS,ErrorCode");
}
FileWrite(fileHandle, TimeToString(TimeCurrent(), TIME_DATE|TIME_SECONDS), Symbol(), "BUY",
DoubleToString(reqPrice, Digits), DoubleToString(fillPrice, Digits),
DoubleToString(slippagePts, 1), DoubleToString(latencyMs, 2), IntegerToString(errCode));
FileClose(fileHandle);
}
}Preserve your own money. Scale with the market's money. Exponential growth is the ultimate key.