Measuring click to fill in milliseconds on MT5: one worked example

[Fairman]

Measuring click to fill in milliseconds on MT5: one worked example

MT5 stores two timestamps on each historical order in milliseconds: ORDER_TIME_SETUP_MSC and ORDER_TIME_DONE_MSC. The difference is roughly how long the trade server took to handle the order. It doesn't include the trip from your machine to the server. Illustrative numbers: setup 09:30:00.412, done 09:30:00.489, so 77 ms.

Now add a local measure. If your EA reads a timer just before OrderSend and again right after it returns, you get the whole round trip. GetTickCount64 has a coarse resolution of around 10 to 16 ms, and GetMicrosecondCount is better. Say you measure 142 ms. Subtract the server side figure and you get about 65 ms for the network and terminal. Both figures are durations, so the difference between your clock and the server's doesn't matter.

What it tells you: on a VPS that shows 5 ms of ping to the broker, a 142 ms round trip means most of the delay is on the broker's side, and moving to a closer VPS can't fix it. If the server figure is low and the total is high, then network or terminal is the culprit.

Use the median and the 90th percentile, not the average, because one slow fill drags the mean around.

[FXS HongKong Scalper]

Good explanation of the two parts. One more factor is the time between the price changing on the chart and the click itself. For manual traders that human delay is usually far larger than the server time. For EAs, measuring the time from receiving a tick to sending the order shows how much the code itself adds. Comparing those numbers during busy and quiet hours can show whether a VPS closer to the server would make a meaningful difference.

[Fairman]

A few hundred orders is enough to start. Record the symbol, the hour in UTC, and both durations. Then compare quiet hours with the hours around data releases. Illustrative numbers of the kind you might see: a median of 60 ms with a 90th percentile of 110 ms in a quiet hour, and a median of 140 ms with a 90th percentile of 420 ms at 13:30 on a release. If your own data looks like that, you've learnt that your fills at releases are slower and more variable, which is useful for deciding whether to trade them. If the numbers are flat across hours, it's useful too.

[Amanhasnoname]

I did this measurement on my own EA last spring and the split was almost the reverse of your example. My server side figure was consistently low, around 30 to 40 ms, but the local round trip was often over 200 ms. The culprit turned out to be my own code. The EA was recalculating a handful of indicators on every tick before calling OrderSend, and on busy ticks that work took longer than the whole server leg.

Moving the calculation to the close of the bar and caching the values brought the round trip down to roughly 70 ms median. Nothing about the VPS or broker changed, which was a useful lesson in checking my own house first before paying for a closer server.

The one detail I'd add to the method is logging the tick time too, the moment the EA received the quote. That gave me a third number, tick to send, and it was the one that actually showed the indicator problem. Without it I would probably have blamed the network and moved providers for nothing.

[Fairman]

Latency only becomes a cost when it's multiplied by price movement. Suppose price moves 2 pips per second in a fast news second, which is an illustrative figure. Then 77 ms is about 0.15 pip, and 300 ms is 0.6 pip. Against a 6 pip stop, 0.6 pip is 10% of the risk. In a quiet minute moving 0.1 pip per second, 77 ms is under 0.01 pip and nobody cares. So the question isn't whether you have latency, but how much of it you have when price is moving. That's why the hour of day belongs in the log next to the millisecond figures. Use pips per second from your own tick log for the hours you trade. A pair at 0.1 pip per second in the Asian morning and 1 pip per second at 13:30 makes the same delay ten times as costly.

[Fairman]

The execution mode of the symbol changes what the timestamps mean. In Market execution the order is filled at the available price with no deviation check. In Instant execution you send a price and a deviation, and if the price has moved beyond it the server can send back a requote, retcode 10004, which means a second attempt and extra time. In Request execution a dealer or a rule has to confirm, which can add much longer delays. So comparing times between two brokers only makes sense if both symbols use the same mode. You can read it from SYMBOL_TRADE_EXECUTION_MODE.

[Fairman]

For a clean log, one row per order with these columns: ticket, symbol, type, volume, requested price, filled price, slippage in pips, server milliseconds, round trip milliseconds, hour UTC, and spread at the moment of sending. Then bucket the slippage by milliseconds, say 0 to 50, 50 to 100, 100 to 250 and over 250, and check the average of each bucket. If longer times go with worse slippage in your own data, that's evidence. If there's no relationship, that's information too, and it might mean the slippage you see comes from price moving around the news, not from your connection.

[Shadow Trader]

The order is sent. The platform shows a spinning wheel, or a blank row, for about 300 milliseconds. It feels longer.

That tiny interval is one of the most stressful moments in scalping, and it rarely gets discussed. Price is moving while the status is unknown. The position might be open, rejected, or half-filled. Every instinct says to click again.

Double-clicking during that window is a well-known cause of duplicate positions. The first click gets through, the second does too, and the position is twice the intended size.

The anxiety comes from lost control. Between click and confirmation, nothing can be changed. A discretionary trader who is used to acting is forced to wait.

Some find that physical habits help, such as taking the hand off the mouse after sending an order. Others use a platform with a visible pending state, so the question of whether it went through has a clear answer.

The wait gets longer in fast markets, which is exactly when the urge to click again is strongest.

What habit stops the second click while an order is still in flight?