Hello,
I have noticed that now BacktestBegin in StrategyMonitor is called one time per each symbol in DataSet (I think that it started to work this way in some recent WealthLab updates).
Is it supposed to work this way?
QUOTE:
BacktestBegin
public virtual void BacktestBegin()
The backtester calls this method for the first symbol (sorted alphabetically) in the universe prior to the backtest beginning its processing.
I have noticed that now BacktestBegin in StrategyMonitor is called one time per each symbol in DataSet (I think that it started to work this way in some recent WealthLab updates).
Is it supposed to work this way?
Rename
Even if "Wait for all Updates before processing" is checked in Strategy Settings?
QUOTE:
Even if "Wait for all Updates before processing" is checked in Strategy Settings?
I'm not checking it because I'm using 1 min candles and in description to "Wait for all Updates before processing" said that it can produce 50 sec delay.
What method of UserStrategyBase should I use for initialization purposes?
The Strategy Monitor will only guarantee 1 backtest (i.e., 1 BacktestBegin) if you select the "Wait for" option. Otherwise, it's going to be run in different groups as the data become available.
You could SetGlobal variable(s) to pick up on subsequent runs if that's really required.
(That said, I'd vote for a change to the Strategy Monitor to "give up" when Streaming or Streaming Bars is selected after, say, 5 seconds.)
You could SetGlobal variable(s) to pick up on subsequent runs if that's really required.
(That said, I'd vote for a change to the Strategy Monitor to "give up" when Streaming or Streaming Bars is selected after, say, 5 seconds.)
QUOTE:
(That said, I'd vote for a change to the Strategy Monitor to "give up" when Streaming or Streaming Bars is selected after, say, 5 seconds.)
It could also be in percents of selected timeframe - 5% of selected timeframe time but no more then 50 sec for example
I'll create this feature request, but the thing is that there's no reason that I can think of right now to delay more than a few seconds when Streaming.
Pure streaming is "done" when the heartbeat closes the interval. That's unlikely to occur even with 1 second delay. Any ticks that come after that are already in the next interval.
The reason I picked 5 seconds is for Streaming Bars. There is often a small delay, usually on the order of 2 to 3 seconds that the server uses to build the historical bar to send. We'd have to test it for several hundred symbols and with different providers to see what a reasonable cutoff should be.
As for polling if no data comes on the second pass, that should be the end of that, imho.
The S. Monitor has come a long way since the early days, and the 50 second "was for updates" rule should be abolished!
Pure streaming is "done" when the heartbeat closes the interval. That's unlikely to occur even with 1 second delay. Any ticks that come after that are already in the next interval.
The reason I picked 5 seconds is for Streaming Bars. There is often a small delay, usually on the order of 2 to 3 seconds that the server uses to build the historical bar to send. We'd have to test it for several hundred symbols and with different providers to see what a reasonable cutoff should be.
As for polling if no data comes on the second pass, that should be the end of that, imho.
The S. Monitor has come a long way since the early days, and the 50 second "was for updates" rule should be abolished!
Your Response
Post
Edit Post
Login is required