Issues with eSignal Ver 10.3

[clearpicks]

When using 2Days Auto timetemplate, the chart stoped updating right after esignal was started. The screenshot was made at 15:13pm. The last quote on chart is still 45.85.

I only tested this issue for $ADD, $VIX and symbols like $SPX, $INDU, ES, NQ, etc. Only $ADD and $VIX have this kind of problems.

[clearpicks]

I reduced the number of charts to minimum, the $VIX,5 chart using 2Days Auto is working fine.

Because in the previous layout, only some scripts using sym("$VIX,5") and sym("$ADD,5") are running on $INDU,5, $SPX, and ES H9,5 charts, which used 2Days Auto. So I suspect the problem is not related to the time template itself. Instead it is something related to efs engine and data manager when esignal is starting and CPU usage is high, in such scenario, the charting engine and efs engine just drop the realtime data stream of "$VIX,5".

I will do more testing.

[clearpicks]

Just as I expected, after changing all charts to Dynamic Auto time template and restarting esignal, the "$VIX,5" chart would stop updating in realtime, however "$VIX,1" is still updating. In this scenario, sym("$VIX") is only running on "$INDU,5" and "$SPX,5" charts.

I am doing more testing.

[clearpicks]

I saw some other posts in this thread http://forum.esignalcentral.com/show...threadid=29638
It seems it is not only me experiencing similar problem in esignal 10.3.

[clearpicks]

Could you guys post the specification of your machine (CPU, memory size, os, etc.), how many charts and scripts running? What is the typical CPU usage when eSignal is starting and after esignal starting? Is there any script accessing secondary symbol/interval? I just upgraded to 10.3 this afternoon and found a similar issue http://forum.esignalcentral.com/show...threadid=29638

[clearpicks]

It must be caused by the code doing "optimization for performance".

[clearpicks]

Now I am able to duplicate the problem on my laptop ( Core Duo T0250, 1GB ).

There is only one dynamic auto time template used.
I created four 5min charts ( $SPX, $NDX, $INDU, ES #F ), on each of them \Helpers\HH.efs and \Helpers\RSIColorLine.efs are applied to inflate the CPU usage at esignal startup stage. My testing script is running on another "ES #F,5" chart and the secondary symbol is set to "NQ H9". An "NQ H9,5" chart and an "NQ H9,1" chart are created to show "NQ H9,5" would stop updating in realtime but "NQ H9,1" would work fine.

The screenshot is attached in this post.

[clearpicks]

I simplified my testing script so I have to add more charts to inflate the CPU usage when esignal starts. The new screenshot is in this post. The script would be in the next post. From the sceenshot it can be tell the NQ H9,5 chart stopped updating right after esignal started but NQ H9,1 was still alive.

[clearpicks]

The testing script.

[clearpicks]

It seems the memory size is not a major reason because there are 3GB in my desktop and it had the same problem after upgrading.

[clearpicks]

No need to run those HH.efs and RSIColorLine.efs. Just open a 5min, 1min and daily charts of NQ H9 without any indicator. Then open an ES H9 5min chart with my testing script running. Exit esignal and restart it. 1Min NQ chart should always update fine, while 5Min and Daily charts may freeze. If they don't, just open more 5Min charts with my testing script running on it, then exit esignal and restart it. On my laptop, I opened an ES H9 and a $INDU 5min charts, on each of them two instances of test_esignal_10_3.efs are applied. Both NQ H9 5Min and daily charts were frozen.

[JayF]

Thanks all for the reports. Our QA staff is investigating this issue, and our developers are actively looking into it.