When a bot waits for one order to fill before sending the next, there's a stretch of time worth looking at: the first order has filled, but the bot hasn't heard yet.
That can happen on a connection that checks for order updates periodically. Until the next check reports the fill, the second order stays unsent. An immediate update in a backtest would let the bot send it sooner, even with exactly the same trading rules.
In the development version of the XTester backtester I'm working on, an optional mode holds those updates until the next check. It models the wait for news of a fill, rather than pushing the fill itself later. Replies to the bot's own requests aren't held back in the same way.
For this kind of strategy, the comparison has a specific question: when did the second order get sent? That exposes any head start created by an immediate notification.
That can happen on a connection that checks for order updates periodically. Until the next check reports the fill, the second order stays unsent. An immediate update in a backtest would let the bot send it sooner, even with exactly the same trading rules.
In the development version of the XTester backtester I'm working on, an optional mode holds those updates until the next check. It models the wait for news of a fill, rather than pushing the fill itself later. Replies to the bot's own requests aren't held back in the same way.
For this kind of strategy, the comparison has a specific question: when did the second order get sent? That exposes any head start created by an immediate notification.
