1m Bar Chart running EFS-AT with latency to snapshot window

[omerproteus]

I am running eSignal 12.2 on an i5 CPU, 8 GB RAM, and SSD HD.

I have seven bar charts each running its own instance of the same EFS-AT script. Each chart shows a major futures contract (e.g. crude, gas, copper, gold, etc). The charts load promptly. The broker connection is good.

On occasions when there is a spike in activity, say around the time of a data release, the chart falls behind the latest tick. I can tell the last traded price in the snapshot window is ahead of the chart. The price in the snapshot bar also matches my broker platform, which further confirms the chart itself is updating late. Hence, the EFS script runs with latent price data.

In the script, I get the latest price using getMostRecentTrade(), but I am not sure that price reflects the true latest price in the snapshot window. The delay in is monitored in the EFS script because I compare the current bar time to the value returned from Quote.lastTime().

Does anyone know if an EFS script can cause delayed price updates in the chart? Does the chart wait for a script to finish running before updating itself (the chart)? I always assumed the chart has priority to the EFS and will work override a "slow" script to make sure the current bar is up-to-date.

Furthermore, if the EFS script execution time is too slow to keep up with spikes in volume or volatile prices, would it then help to force the script to "skip" a bulk of its functionality in order to conserve time until the latency has ended. Again, latency is measured by the difference in the current bar rawtime and Quote.lastTime().

This issue was observed in previous versions of eSignal, but the latency has gotten somewhat worse recently.

Has anyone come across this problem and identified a possible resolution?

[eSignal_AveryH]

Hello omerproteus,

“Does anyone know if an EFS script can cause delayed price updates in the chart? Does the chart wait for a script to finish running before updating itself (the chart)? I always assumed the chart has priority to the EFS and will work override a "slow" script to make sure the current bar is up-to-date.”

A chart and an EFS are executed synchronously. So an EFS can be a cause of price updates in a chart. When every new tick comes in a chart then the chart waits until an EFS is calculated on this new tick.

“Furthermore, if the EFS script execution time is too slow to keep up with spikes in volume or volatile prices, would it then help to force the script to "skip" a bulk of its functionality in order to conserve time until the latency has ended. Again, latency is measured by the difference in the current bar rawtime and Quote.lastTime().

This issue was observed in previous versions of eSignal, but the latency has gotten somewhat worse recently.

Has anyone come across this problem and identified a possible resolution?”

We can suggest to get the actual time of a last trade from separate thread – in other words from another efs running in a separate chart - and pass to your trading efs script using setGlobalValue()/getGlobalValue(). So in this case in your efs script you can compare the time of processing of the current tick on a chart and the actual time of the last tick. If this delay is too large you can skip the heavy functionality in the script until your thread is aligned with the actual data.



AveryH
eSignal Support

[omerproteus]

AveryH, thanks for making that important clarification regarding the priority of script execution. That is the central cause of this issue.

Your suggestion for tracking the last trade seems correct. Currently, I use the following code to extract the system time.

var sys_time = new Date();
var h = sys_time.getHours();
var m = sys_time.getMinutes();
var s = sys_time.getSeconds();

I convert this system time to a basis which can be compared to Quote.lastTime(). That is how I detect latency in the chart. Your suggestion is even better, but I wanted to avoid building more charts and running additional scripts.

In the end, I need to figure out how to address this issue. Overriding part of my script will save execution time, which in turn should help the chart catch up to real time.

[odgo]

Hello omerproteus,

In eSignal v12.2 I also have noticed significant delays between a chart's updated price and the current real-time price, and there does not have to be a "fast" market for this to occur. I suspect the problem is related to the EFS-AT function calls and/or changes that were made to those calls in migrating past v12.0. If I return to v12.0 my scripts run as they should without obvious delays in chart updating. If you have the time, you might try running your scripts under the previous version and see if they behave properly. The previous v12.0 can be downloaded from:

32bit: http://download.esignal.com/products...0.3598_x86.exe

64bit: http://download.esignal.com/products...0.3598_x64.exe

If performance improves and the delays disappear, the question becomes, What did the developers change in going from v12.0 to the later versions, and for whatever they gained was it worth the new added slowness? Avery's suggestion sounds klugey as well as a lot of work and might lead to unforeseen interactions and complications. I would consider changing platforms before I would go that route.

odgo

[omerproteus]

I decided to continue with ver 12.2 but skip executing a portion of the EFS code when the chart is lagging. The lag effect (i.e. latency) is measured by comparing the latest price rawtime in a separate Watch List running EFS to that of the Chart. As a result, chart latency is shorter and less frequent, although still occurs whenever volatility rises for several seconds. My objective was to minimize latency, not absolutely eliminate it.

As odgo pointed out, this latency issue may well be the result of the latest release. I do not check isConnected unless absolutely required. Other than that, the other source of delay may be calls to the Position object. Minimizing calls to these objects seems to have material benefits in terms of time.

Since EFS is not suited to HFT or trading which requires 1 second resolution, I do not see a latency of a few seconds as severely problematic. Beyond a few seconds, modifying code to improve processing speed seems reasonable.