Latency to broker: measuring from EA OnTick timestamps

[LondonScalper]

I measure path delay with timestamps I control, not with slogans.

A simple EA logging OnTick time against an NTP-synced clock on the VPS gives me a crude distribution of gaps. Spikes cluster around news and around VPS load. That is enough to tell me when the machine is sick. It is not enough to claim a microstructure edge.

How I set it up: the EA writes GetTickCount64 and TimeCurrent for every tick to a CSV, plus the tick's own time from SymbolInfoTick. A small Python script reads the file on Sunday and plots the median and 99th percentile gap per hour. Nothing fancy, maybe forty lines total. The interesting chart is not the median, which barely moves, but the tail during the first minute of London.

One caveat: tick time from the server is not the same as when the tick left the liquidity provider. You are measuring part of the path, not the whole thing.

When the distribution worsens for a week, I strip charts and reboot before I blame the broker. Latency theatre without a baseline is just anxiety with numbers.

[Fairman]

the EA writes GetTickCount64 and TimeCurrent for every tick to a CSV, plus the tick's own time from SymbolInfoTick

A couple of resolution details that matter for the tail you're looking at. TimeCurrent only has one-second resolution, so it can't show anything below a second. The MqlTick structure from SymbolInfoTick has time_msc, the server's tick time in milliseconds, and that's the field to compare against. On the local side, GetTickCount64 follows the Windows system timer, which typically updates every 10 to 16 milliseconds, so gaps measured with it come in steps of that size. GetMicrosecondCount gives a much finer local clock for measuring differences. Comparing time_msc with an NTP-synced local time also bakes in whatever offset exists between the two clocks, so the absolute number isn't meaningful, but changes in it are, which is what the hourly percentile chart really shows anyway.

[Shadow Trader]

Resolution detail already covered time_msc and GetMicrosecondCount well. What I add is operational: strip charts and reboot before blaming the path when the weekly tail worsens.

The chart that matters is the 99th percentile during the first London minute, not the calm median. Median barely moves week to week; the open tail is where VPS load and queue depth show up.

Absolute offset between server time_msc and local NTP is meaningless for ranking brokers. Changes in that gap across weeks are what I act on, after I have ruled out a sick machine.

I still plot median and 99th per hour on Sunday from the CSV. Spikes that only appear on release minutes get a separate tag so they do not poison the open baseline.

Strip and reboot has fixed more scary weeks than a broker ticket. Do you gate any path complaint behind a clean machine check first?

[Shadow Trader]

LondonScalper, one thing that can quietly distort that CSV is the logging itself. Flushing a line on every tick means disk I/O inside OnTick, and on a small VPS that added a few milliseconds to my open tail.

I now buffer rows in memory and flush every 500 lines or every 10 seconds, whichever comes first. The open 99th percentile dropped about 3 ms after that, so part of my scary tail was self inflicted.

There is also coalescing to account for. If the EA is still busy when new ticks arrive, the terminal does not queue a fresh OnTick for each one, so a long handler hides ticks and makes gaps look worse than the path is.

To catch that, I compare the count of OnTick calls per minute with the ticks CopyTicks returns for the same minute. When the two diverge at the open, the problem lives in my code, not between me and the server.

I also wrap the handler in GetMicrosecondCount to log its own run time. Anything over 2 ms gets a row of its own.

Have you checked how many ticks your logger skips at the London open compared with what the history holds? Mine skipped more than I expected on the first test.