I have seen a statement below regarding the delay retrieving the new bar on Strategy Monitor.

QUOTE:
Strategy Monitor: Schedules a run for the end of the next interval and when it arrives (based on your system clock), 1) waits 5 seconds to ensure the historical bar is available on the server, 2) requests an update (delay to server), and 3) receives the update (delay from the server). So that's 5 seconds + Round trip delay. Furthermore, Fidelity updates 10 symbols at a time per Strategy. So, if you have 50 symbols, multiply the round trip delay by 5.

Is this still applicable to WLP6.8? I'm wondering if Strategy Monitor yet takes more than 5 seconds longer than Streaming Window for retrieving a new bar data. I'm wondering if I can migrate tens of Streaming Windows to Strategy Monitor.

QUOTE:
Is this still applicable to WLP6.8?

No, that was the original static bar request design, which changed in 6.4 to "streaming bars". In the current design, the S. Monitor subscribes once and the bars are pushed out when they're ready. A back end delay still exists to form the static bars, and this is typically 5 to 7 seconds for a 5 minute bar, more for higher bar intervals.

If it's important to execute the strategy as close to the end of interval as possible, use streaming windows.

QUOTE:
this is typically 5 to 7 seconds for a 5 minute bar, more for higher bar intervals

How about 1 minute bar for less than 10 symbols? What if I have more symbols for 1 minute bar, say 30 symbols?

QUOTE:
If it's important to execute the strategy as close to the end of interval as possible, use streaming windows.

Yes, I understand that but I'm having more and more streaming windows and wondering if consolidating into strategy monitor.

Mileage varies. Just give it a try. You're very capable to evaluate if it works for you or not.

Note:
Although the bars are pushed to the S. Monitor, processing is kicked off based on the system clock. Make sure that the clock is synchronized to internet time.

QUOTE:
You're very capable to evaluate if it works for you or not.

Yes, I did it this morning and so far Strategy Monitor is taking extra 3s time on average compared to Streaming Window (spread from 2.5s to +3.5s). Does this make sense for a 1 minute bar?

QUOTE:
Although the bars are pushed to the S. Monitor, processing is kicked off based on the system clock.

Curious but why you need to wait for the system clock to kick off if the bars are pushed already?

QUOTE:
Make sure that the clock is synchronized to internet time

All my computer's clock is synchronized at every hour so the system clock is reliable.

1. Yes. The historical server has to build the bar before it's ready to send out, and it does this for all supported intervals. The streaming window builds the bar on the fly with the ticks, so this bar is immediately ready at the end of interval. That's why, "If it's important to execute the strategy as close to the end of interval as possible, use streaming windows."

2. It's the design (not mine).

3. Sounds good.

1. So that means the difference between Streaming Window and Strategy Monitor is:
Streaming Window builds the bar by itself from the tick data received from Server.
Server builds the bar and sends it to Strategy Monitor.

If that is the case, Streaming Window may build incomplete bar data than the Server builds it for Strategy Monitor if by any chance Streaming Window missed some tick data? I'm assuming Streaming Window accumulates the ticks.

QUOTE:
If that is the case, Streaming Window may build incomplete bar data than the Server builds it for Strategy Monitor if by any chance Streaming Window missed some tick data?

While Robert should know about the Fidelity streaming feed, on a more general note, some streaming data providers are based on partial OHLC bars returned by their feed instead of relying on tick updates. This depends on feed's capability to deliver partial bars. Consequently, they're free from issues related to potentially missing ticks.

Sure, if the data doesn't make it to the application, it's going to miss it. But why would the Streaming window miss tick data? It's a socket connection, and in my experience I've never seen that happen.

More likely is the case of a bad initialization of a bar-in-progress. To initialize any streaming window Wealth-Lab sends a historical request from the static provider, which needs to request the partial bar if one is in progress. If that partial bar is not initialized properly, there's a chance that that bar (and only that bar) will be missing the correct High and/or Low price. I recall this being an issue at one point but don't know if it still is. Again, if this were still a problem, it would only manifest itself if you were switching symbols or refreshing streaming windows during the market session.

Thank you for the clarification. That sounds explaining an awkward I have seen intermittently after restarting WLP or reopening Workspace during the market session.

I have since switched all streaming windows to strategy monitor and working great so far.
This is much easier to manage many streaming windows.