forex-scalping.com

I had an EA that occasionally got "invalid stops" errors on gold and some indices. The cause was simple: my stop calculation produced prices like 2351.237 on a symbol with a tick size of 0.01, or 0.05 on some index CFDs.

The fix is a small function that rounds the price to the nearest multiple of SYMBOL_TRADE_TICK_SIZE, then normalises it to the symbol's digits:

• Read SymbolInfoDouble(sym, SYMBOL_TRADE_TICK_SIZE).
• price = MathRound(price / tick) * tick.
• Then NormalizeDouble(price, digits).

NormalizeDouble alone isn't enough when the tick size is larger than one point, which is common on indices.

I also round in the safe direction for stops: down for a long stop, up for a short one, so risk is never larger than planned. Same for lot sizes, rounded down to the volume step.

After the change, zero invalid stop errors in three months. Has anyone else run into tick size issues on CFDs? It seems most EA examples only consider FX.

An EA runs its logic on each new tick. That sounds fast. Whether it is depends on what happens inside.

A loop that scans two hundred bars of history, recalculates five indicators, and checks a dozen conditions on every tick might take only a few milliseconds on a quiet market. On a busy one, ticks arrive faster than the code can finish, and they queue.

The platform may skip ticks or process them late. The EA ends up reacting to a price that's already stale. That's a cost invisible in backtesting, where processing time isn't modelled.

Several things help. Calculating indicators once per bar instead of every tick. Caching values instead of recomputing them. Keeping order-send calls out of loops. Measuring how long each tick takes to handle and logging anything slow.

On a VPS shared with other applications, CPU spikes add more variation.

A simple test is to log the time at the start and end of the tick handler during a high-volatility session. The numbers can be surprising.

Has the processing time of an EA ever been measured, and was any of it a surprise?