Eugene/Robert,

I have been using a strategy on 3min candles with TNA & TZA for several months. The strategy creates “Buy Stop” orders on the High of the last candle. I have been running the strategy in a Window on TNA and in the Strategy Monitor on a Data Set that contains TNA & TZA. Yesterday I noticed that the Window and the Monitor generated Order Alearts at different times. I also noticed that the Monitor orders were not always the same value of the last High that was displayed on the chart in the Window.

I used the code from the Wiki that exported data to a file in the Strategy Monitor and compared the data to that “Copied to the Clipboard” from the Window. The TNA data is displayed below:

The data was the same until 10:09. After that the Price and Volume data started to differ. You might notice that the High data at 10:30 was very different.

Open High Low Close Vol
Monitor 12/9/2011 10:03 43.28 43.67 43.22 43.6687 298839
Window 12/9/2011 10:03 43.28 43.67 43.22 43.6687 298839

Monitor 12/9/2011 10:06 43.64 43.9301 43.5152 43.91 502147
Window 12/9/2011 10:06 43.64 43.9301 43.5152 43.91 502147

Monitor 12/9/2011 10:09 43.9002 43.98 43.7599 43.91 249730
Window 12/9/2011 10:09 43.9002 43.98 43.7599 43.94 353432

Monitor 12/9/2011 10:12 43.92 44.1189 43.85 44 333041
Window 12/9/2011 10:12 43.92 44.1189 43.85 44.03 428570

Monitor 12/9/2011 10:15 44.04 44.11 43.891 43.93 181699
Window 12/9/2011 10:15 44.04 44.11 43.8 43.87 256668

Monitor 12/9/2011 10:18 43.8802 44 43.75 43.95 182519
Window 12/9/2011 10:18 43.8802 44 43.75 43.94 260087

Monitor 12/9/2011 10:21 43.93 43.95 43.73 43.76 143823
Window 12/9/2011 10:21 43.93 43.95 43.73 43.87 206008

Monitor 12/9/2011 10:24 43.86 43.92 43.72 43.84 129904
Window 12/9/2011 10:24 43.86 43.92 43.72 43.82 171543

Monitor 12/9/2011 10:27 43.83 43.93 43.65 43.68 111668
Window 12/9/2011 10:27 43.83 43.93 43.43 43.44 283025

Monitor 12/9/2011 10:30 43.44 43.67 43.43 43.59 103497
Window 12/9/2011 10:30 43.44 43.74 43.43 43.74 139760

Monitor 12/9/2011 10:33 43.75 43.82 43.57 43.68 74943
Window 12/9/2011 10:33 43.75 43.8598 43.57 43.8295 136198

Monitor 12/9/2011 10:36 43.83 43.96 43.82 43.93 164792
Window 12/9/2011 10:36 43.83 44 43.81 43.83 267611

I tried this on 1 min candles and did not find a problem. I did not try this on other time periods but the problem certainly exists on 3 minutes.

Could you please find out if Fidelity changed something in the data feed or if there is some way of fixing this problem?

Thanks.

Robert/Eugene,

I have been looking at this some more and it appears that in the Monitor the 3min candles initially are the same as in the Window but soon start to contain only the data from the first two 1 min of each 3min candle:

________________________________Open____High____Low_____Close___Vol
1-minute 12/9/2011 12:10 45.04 45.09 45 45.0489 43951
1-minute 12/9/2011 12:11 45.04 45.14 45.03 45.0999 61088
1-minute 12/9/2011 12:12 45.1081 45.12 45.04 45.04 50010
3-minute 12/9/2011 12:12 45.04 45.14 45 45.0999 105039

1-minute 12/9/2011 12:13 45.05 45.11 45.04 45.08 22425
1-minute 12/9/2011 12:14 45.1001 45.14 45.09 45.11 38912
1-minute 12/9/2011 12:15 45.1 45.23 45.09 45.19 49590
3-minute 12/9/2011 12:15 45.05 45.14 45.04 45.11 61337

Notice that the Volume of the 3min is equal to the total of the first two 1min candles. The 3min prices also correspond to the combination of the first two 1min candles.

Since the Monitor uses different data from the Server than the streaming Window, it would seem that Fidelity has recently done something to the Server. Could you please pass this info to Fidelity.

Thanks

Hi Ray, we always finds ourselves in the middle of vendor data issues, but we can't help here. Customers must call in data issues to the vendors.

That said, you've made good observations. Do you know if this phenomenon is relatively new? You may have heard that the way the data feed to the S. Monitor is getting a huge facelift in 6.3 (est. January), front-end and back-end. This isn't something that should be affecting production data, but I mention it because there will be changes coming up. What I can do is to tip off Fidelity QA to check the accuracy of 3 min bars while testing the new feed.

Update:
We followed up, duplicated the problem, verified Ray60's spot-on analysis, and finally determined that this indeed is a Wealth-Lab client app problem with the S. Monitor integration with the Fidelity Provider. This is fixed for 6.3 (eta: late Jan.) Thank you for spotting this and many apologies for all the trouble.

Robert,

I just installed Ver 6.3 and the problem is still there. I looked in the Wiki under "Open Issues" and could not find any reference to the problem. I may be wrong but I thought this was listed there before.

Thanks.

Hi Ray, you're right. This should have been fixed and Fidelity is actively looking at it now and considering releasing a patch as early as next week. My apologies for letting this slip through the cracks, but hopefully there will be a quick resolution.

More notes:
1. The problem apparently affects 60-minute bars as well. In other words, 60-minute bars contain only the first 30-minutes of data.

2. Although the S. Monitor and Fidelity Streaming Provider were "ready" for the S. Monitor data enhancement, there were issues that couldn't be resolved in time on the back end. Therefore that upgrade has to wait for 6.4 now. :(

Update:
The bad news is that there will not be a patch release to address this issue, but the good news is that there is a relatively simple work-around. First I'll describe it and then give you more background.

Workaround:
1. In your machine's Date and Time properties > Internet Time, disable automatic synchronization.
2. Set your local clock with a 5 second delay.
(One way to do this is by watching the time of sales of an active symbol in AT Pro. For example, when a trade goes off at, say, 09:25:05, enter 09:25:00 for the local time.)

Background:
This issue has a potential to occur only:
1. for non-native intraday intervals (any interval excluding 1, 5, 10, 15, and 30, and,
2. when using the Static Provider for requests.

Briefly, the problem occurs when WLP has to conflate data from multiple intervals (e.g., use three 1-minute bars to create a 3-minute bar) and the history server is not ready with the latest data when WLP requests it the first time. WLP is not ensuring that it receives all the bars required. The workaround gives the server additional time (5 seconds seems to be sufficient) to store the historic bar so that they are ready for WLP's first request.

In 6.4 (summer?) this will no longer be an issue since the static provider will no longer be used to poll for intraday data.

Robert,

Could you reflect the problem summary on the Open Issues list, please?

QUOTE:
(One way to do this is by watching the time of sales

Another way is to use an internet time server that shows seconds, for example:
http://www.timeanddate.com/worldclock/city.html?n=179