What does the following message mean when they appear in Stategy Monitor?

Skip Update (not current): CUZ(153)

Does it mean symbol CUZ could not be updated at bar 153?

I think that this is a chunk of 153 (intraday?) bars for CUZ. The data is not current, there's nothing to update, so processing this symbol has to be stopped and it's time to move to next action.

I'm getting the same skip update message on multiple symbols. For example, if I run the following setup with Fidelity steaming:

"Intraday Breakout system", S&P 100 watchlist, 300 bar Range, 15 Min (or 30 Min) interval

not all the alerts show up. I think most S&P 100 stocks are active enough that bars don't have to be skipped.

I'm using WLPro 6.4 x64 with 12Gb of memory so there shouldn't be any system resource issues.

As a check, if I run the Strategy Window on the same watchlist, all the alerts do show up. So what can be done to fix this skip update issue?

Very well could be the Western/Eastern time zone thing. It's just an educated guess, but based on the timestamp, the data provider might be thinking that the data received during a Strategy Monitor update is not actual in the current time zone.

I fixed the time zone and as a check, the strategy window does show correct number of bars and timestamp. So clearly something else is going on here.

When a strategy is initially activated in Strategy Monitor, the data is updated and written to hard disk as checked by Data Manager. But by the next update period, the data is not written to hard disk (as checked by Data Manager). Is this correct?

Should I enable the Update Data on Demand while using the Strategy Monitor?

QUOTE:
Is this correct?

Yes for 5-min intervals and lower. Higher Data Store intervals (10,15, 30 min) are disk-cached since these files are not as large and therefore don't take a significant amount of time to write.

Update Data on Demand has no effect on S. Monitor operation.

CODE:
Please log in to see this code.

More specifics required. Right-click the item and enable logging. After a couple of runs that demonstrate the problem, view the log and paste it here or in a support ticket with a summary of the symbols that are suspected of not updating or missing alerts.

QUOTE:
the strategy window does show correct number of bars and timestamp. So clearly something else is going on here.

The Strategy window timestamp shouldn't make difference. Whatever the server has, will be reflected on your chart. The SM is different in this aspect: it compares the DateTime in bars it received during scheduled interval update and if it's not actual (as it thinks), the bars will not be appended -- hence "Skip Update (not current)".

I also have the same problem of 'Skip Update(not current). I had removed the 6.4 version and reinstalled the 6.3.

What time zone are you in?
What bar scales does it affect?
Which symbols?
Which data provider are you using?
Did reinstalling have any effect?

60m bar.
I used IPHS symbol.
Data Provider - Fidelity.
Reinstalling 6.3 generated a sell signal where 6.4 never did.

Thanks for the information.

I just generated some log files from SM. Just a snippet from the log. I'll attach the rest in the support ticket.

In summery, even though the data is updated, skip update message is logged. For example, AAPL is updated but a few lines down,

QUOTE:

11/21/2012 10:30:51 AM: Update Completed: AAPL, LastDate=11/21/2012 10:30:00 AM, O=562.85 H=562.9399 L=558.052 C=558.72 V=1740369 Count=302, AAPL,OHLCV
11/21/2012 10:30:51 AM: Update Completed: AMGN, LastDate=11/21/2012 10:30:00 AM, O=86.72 H=86.75 L=86.475 C=86.57 V=294698 Count=302, AMGN,OHLCV
11/21/2012 10:30:51 AM: Update Completed: AMZN, LastDate=11/21/2012 10:30:00 AM, O=234.46 H=234.84 L=232.78 C=233.3 V=260861 Count=302, AMZN,OHLCV
11/21/2012 10:30:51 AM: Update Completed: BA, LastDate=11/21/2012 10:30:00 AM, O=73.77 H=73.86 L=73.51 C=73.62 V=527735 Count=302, BA,OHLCV
11/21/2012 10:30:51 AM: Update Completed: COST, LastDate=11/21/2012 10:30:00 AM, O=97.02 H=97.02 L=96.79 C=96.84 V=87855 Count=302, COST,OHLCV
11/21/2012 10:30:51 AM: Update Completed: CSCO, LastDate=11/21/2012 10:30:00 AM, O=18.365 H=18.45 L=18.29 C=18.45 V=3351889 Count=302, CSCO,OHLCV
11/21/2012 10:30:51 AM: Update Completed: DD, LastDate=11/21/2012 10:30:00 AM, O=42.8 H=42.82 L=42.58 C=42.73 V=296104 Count=302, DD,OHLCV
11/21/2012 10:30:51 AM: Update Completed: DELL, LastDate=11/21/2012 10:30:00 AM, O=9 H=9.02 L=8.98 C=9 V=2282952 Count=302, DELL,HLV
11/21/2012 10:30:51 AM: Update Completed: GD, LastDate=11/21/2012 10:30:00 AM, O=64.15 H=64.32 L=64.05 C=64.16 V=116663 Count=302, GD,OHLCV
11/21/2012 10:30:51 AM: Update Completed: HD, LastDate=11/21/2012 10:30:00 AM, O=63.83 H=63.88 L=63.67 C=63.6901 V=583289 Count=302, HD,OHLCV
11/21/2012 10:30:51 AM: Update Completed: EBAY, LastDate=11/21/2012 10:30:00 AM, O=48.28 H=48.46 L=48.22 C=48.29 V=530800 Count=302, EBAY,OHLCV
11/21/2012 10:30:51 AM: Update Completed: GE, LastDate=11/21/2012 10:30:00 AM, O=20.72 H=20.72 L=20.62 C=20.655 V=2447801 Count=302, GE,OHLCV
11/21/2012 10:30:51 AM: Update Completed: BRKB, LastDate=11/21/2012 10:30:00 AM, O=87.24 H=87.33 L=87.0648 C=87.12 V=320633 Count=302, BRKB,OHLCV
11/21/2012 10:30:51 AM: Update Completed: GILD, LastDate=11/21/2012 10:30:00 AM, O=75.7 H=75.7199 L=74.93 C=75.08 V=372569 Count=302, GILD,OHLCV
11/21/2012 10:30:51 AM: Update Completed: GOOG, LastDate=11/21/2012 10:30:00 AM, O=664.695 H=664.84 L=660.4 C=660.82 V=237447 Count=302, GOOG,OHLCV
11/21/2012 10:30:51 AM: Skip Update (not current): AAPL (302)
11/21/2012 10:30:51 AM: Update Completed: INTC, LastDate=11/21/2012 10:30:00 AM, O=19.515 H=19.52 L=19.28 C=19.3301 V=8219259 Count=302, INTC,OHLCV
11/21/2012 10:30:51 AM: Update Completed: BK, LastDate=11/21/2012 10:30:00 AM, O=24.09 H=24.0997 L=23.97 C=24.005 V=408401 Count=302, BK,OHLCV
11/21/2012 10:30:51 AM: Skip Update (not current): AMGN (302)
11/21/2012 10:30:51 AM: Update Completed: CL, LastDate=11/21/2012 10:30:00 AM, O=106.57 H=106.71 L=106.2 C=106.22 V=134786 Count=302, CL,OHLCV
11/21/2012 10:30:51 AM: Skip Update (not current): AMZN (302)
11/21/2012 10:30:51 AM: Skip Update (not current): BA (302)

Thanks for the data. It looks to me like the data is arriving much too late - after 50 seconds (assuming that your local clock is accurate). It's expected that higher intervals, like 15 and 30 minutes, take longer for the server to "produce", but I'd have to say that this kind of responsiveness is not expected, and not acceptable. I'm going to run some tests here and see if I'm seeing that same kind of delay. Hopefully it's just a lagging server that needs to be isolated.

I have the clock synchronized with time.microsoft.com and double checked at time.gov.

If you open the attached file in the support ticket, the update does start on time at 10:30:00 AM for the above example. However, it does take time to update all the symbols in S&P 100 watchlist.

Also, one of the above posters said that he doesn't see this problem in WL 6.3. If so I'll try to install v6.3 and test it.

I didn't see a problem for the 3:00, 3:30, and 4:00pm updates. In all cases, the S&P 100 symbols (30-min bars) updated and finished executing the strategy within 15 seconds after the interval mark.

For sure things changed from 6.3 to 6.4. 6.4 uses a "streaming bar feed" and will certainly update much faster than 6.3, which polls for updates 10 symbols at a time. The difference is that 6.3 allowed more time for symbol updates to be received because the process is much slower. It seems that in 6.4, this window could have been reduced to a maximum of 50 seconds for all intervals, which is at least twice as long as updates are expected to be received. Generally, all updates - regardless of the number of symbols - should occur within 10 seconds in WLP 6.4 (Fidelity Provider).

I should mention that when the log was collected, I had 3 or 4 other application programs also running, ie Fidelity ATP, web browser, spreadsheet. Maybe I shouldn't have but with 12Gb of memory, I should be able to muti-task.

I also just tested my broadband speed to NY and to the farthest place from me, Seattle. They averaged download speed of 5.6Mpbs. No problem there.

One final point. It seems likely that greater the number of symbols, more likely to skip updates will happen (due to delay).

QUOTE:
Generally, all updates - regardless of the number of symbols - should occur within 10 seconds in WLP 6.4 (Fidelity Provider).

So in theory, I should be able to update all of Russell 2000, ie 2000 stocks, at say 30 min intervals and at 300 bars range? I will try Russell 2000 next time and report on the log.

For 6.3, you couldn't possibly request even 1000 symbols before the window expired. For 6.4, the number of symbols really shouldn't matter substantially since these data are "pushed" to you when available on the server. As I mentioned, it seems to me that there's a slow server out there. The updates for thousands of symbols should all be received within seconds (For me the S&P 100 updates in seconds). However, keep in mind that the machine has to execute the strategy and also write/cache all of that data to disk (for intervals above 5 minutes), which means saving thousands of files. The length of those processes will vary by machine.

I collected more logs. I ran two strategies (Intraday Breakout system and Delayed Channel Breakout). Each strategy ran on two different intervals of 15 min and 30 min on S&P 500 watchlist with 300 bar range. No other application was running besides WL.

The results were similar to as before. Every data update that stretches beyond 50 seconds logs Skip Update. A cut out sample of log recording Skip Update:

QUOTE:
11/23/2012 11:15:51 AM: Skip Update (not current): CLF (303)
11/23/2012 11:15:51 AM: Skip Update (not current): ACE (303)
11/23/2012 11:15:51 AM: Update Completed: F, LastDate=11/23/2012 11:15:00 AM, O=11.085 H=11.09 L=11.08 C=11.085 V=472094 Count=303, F,OHLCV
11/23/2012 11:15:51 AM: Skip Update (not current): AEE (303)
11/23/2012 11:15:51 AM: Skip Update (not current): CBE (303)
11/23/2012 11:15:51 AM: Skip Update (not current): CCE (303)
11/23/2012 11:15:51 AM: Skip Update (not current): CME (303)
11/23/2012 11:15:51 AM: Skip Update (not current): DTE (303)
11/23/2012 11:15:51 AM: Skip Update (not current): GME (303)
11/23/2012 11:15:51 AM: Skip Update (not current): ICE (303)
11/23/2012 11:15:51 AM: Update Completed: IFF, LastDate=11/23/2012 11:15:00 AM, O=64.26 H=64.3 L=64.17 C=64.21 V=4300 Count=303, IFF,OHLCV
11/23/2012 11:15:51 AM: Skip Update (not current): ANF (303)

Cone,

I think the 'Skip Update(not current)' problem is the reason that I have missed my alerts/signals in the problems I reported previously.
Mine is a 60m interval, I would understand maybe if it was a 5m one.

Although the logic for aborting runs after the 50-second cutoff (confirmed) for data appears flawed (and will be reviewed for the next release), the data shouldn't be taking that long to get there in the first place. My belief is that there is a latent server out there. Anyway, for sure the higher intervals (like 15, 30) will generally take longer to arrive than lower intervals because there is more back-end processing required to conflate the data.

Cone,

Any idea when the fix is going to be released. I really like the performance of 6.4 and would like to start using it. Bugs associated with back tests can be tolerated but bugs in SM can be costly.

Receiving updates 30 to 50 seconds after the end of interval is out of spec and that's a particular server problem (I'm not seeing this poor performance on my connections), which could change at any time. Likewise, canceling runs for updates have been received is wrong too and I'm sure Fidelity will look at compensating for it the next release cycle.

The Fidelity data team is investigating. For anyone still experiencing the issue, it would help to have a fresh set of logs that show the problem. If you can assist, please let me know or just create a ticket and attach your log.

@abate - Are you using Windows 8 too?

No I am using windows 7. I would love to assist in resolving the issue but I dowgraded to 6.3.

System: Winows XP x86, 4GB RAM, Core2 Quad

Strategy: Delayed Channel Breakout
Data: S&P 100, 15 Min, 300 bars
Result: No skip

Strategy: Delayed Channel Breakout and Intraday Breakout system
Data: S&P 100, 15 Min, 300 bars
Result: No skip

Strategy: Delayed Channel Breakout
Data: S&P 500, 15 Min, 300 bars
Result: Skips

QUOTE:
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: ABT Delayed Channel Breakout
12/4/2012 2:30:56 PM: Skip Update (not current): COV (302)
12/4/2012 2:30:56 PM: Skip Update (not current): DTV (302)
12/4/2012 2:30:56 PM: Update Completed: CVX, LastDate=12/4/2012 2:30:00 PM, O=104.08 H=104.34 L=104.08 C=104.25 V=245834 Count=302, CVX,OHLCV
12/4/2012 2:30:56 PM: Skip Update (not current): ESV (302)
12/4/2012 2:30:56 PM: Skip Update (not current): DOW (302)
12/4/2012 2:30:56 PM: Skip Update (not current): GLW (302)
12/4/2012 2:30:56 PM: Skip Update (not current): GNW (302)
12/4/2012 2:30:56 PM: Skip Update (not current): GWW (302)
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: BBT Delayed Channel Breakout
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: HOT Delayed Channel Breakout
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: EQT Delayed Channel Breakout
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: AMT Delayed Channel Breakout
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: BTU Delayed Channel Breakout
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: AIV Delayed Channel Breakout
12/4/2012 2:30:56 PM: Creating Executor
12/4/2012 2:30:56 PM: Execute: IGT Delayed Channel Breakout
12/4/2012 2:30:56 PM: Update Completed(2): XOM (470 symbols left)
12/4/2012 2:30:56 PM: Leaving Update Completed
12/4/2012 2:30:57 PM: Creating Executor
12/4/2012 2:30:57 PM: Execute: CAT Delayed Channel Breakout
12/4/2012 2:30:57 PM: Skip Update (not current): DOV (302)

So there is a limit to number of symbols that can be updated before skips due to data delay or/and slow processing of the script. So 50 sec data reset is not appropriate across all number of symbols and all scripts with different time intervals.

There's definitely a problem that we're trying to get to the bottom of. The fact that that log is saying (470 symbols left) at 56 seconds after the top of the interval is suspect. It's hard to imagine that kind of [bard] performance. Richard, so that we can get all the details, could you attached that full log to your ticket, please?

Updated few more logs to the ticket.

Note: For 9:45 AM log, I meant to say system clock was delayed by 15 sec, not advanced by 15 sec.