Hey everyone,
any news about this issue yet?
Severely delayed chart updating in MC / eSignal
-
Alex Kramer
- Posts: 834
- Joined: 23 Feb 2006
We are aware of the lag issues and are working on optimization.
One thing I can say - there will never be a piece of news saying "Now, the performance of MultiCharts is always perfect, independent of hardware used and indicators applied".
We appreciate your interest and high expectations from our product, but there's reality. It is known that well-written indicators like Jerry's demand a fraction of resources consumed by unoptimized ones.
One thing I can say - there will never be a piece of news saying "Now, the performance of MultiCharts is always perfect, independent of hardware used and indicators applied".
We appreciate your interest and high expectations from our product, but there's reality. It is known that well-written indicators like Jerry's demand a fraction of resources consumed by unoptimized ones.
-
Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
I'm reading the messages in this forum topic with interest too. It was suggested in one message or two that since two applications sharing the same data vendor [esignal] would imply that BOTH applications are receiving the SAME data at the SAME time. Though this sounds reasonable, it might not really be true 
. Consider that each application sets up its own and separate 'request' for data for a particular symbol and date/time range.
Does anyone in this forum really know how the esignal handles these separate request? Is it possible, for example, that separate TCP/IP sockets are required/setup for each application using the eSignal datafeed?
I have also noticed that some applications I have that also use eSignal are registered in the esignal-DataManager as TWO 'users', instead of the 'expected' ONE user. I am limitead to a total of 4 users on my one esignal account, so I like that MC is only 'one user' of esignal- datafeed.
In any case, even IF separate sockets are used by separate applications on the same machine, I don't think that must necessarily imply that eSignal's servers are responding equally fast to multiple 'requests' for the same data symbol (especially during very high tick volume, being delivered to thousands of esignal subscribers!).
I have a question concerning 'time-stamps' for each tick. Are those time-stampls supplied by eSignal (or in the case of FX, by the individual 'contributors' for a specific symbol), OR are these time-stamps supplied by the MC-QM processing? If those time-stamps are supplied at the 'source', then it is theoritically possible to calculate the delay-lag by comparison to some 'atomic-clock' ticks available over the internet connection, right? IF we had the capability to monitor and measure the relative time-arrival of each tick relative to its origination-time-stamp then we could all probably know a lot more about what/where any lag is coming from, until then I would not discount eSignal's servers as being a 'problem'.
. Consider that each application sets up its own and separate 'request' for data for a particular symbol and date/time range. Does anyone in this forum really know how the esignal handles these separate request? Is it possible, for example, that separate TCP/IP sockets are required/setup for each application using the eSignal datafeed?
I have also noticed that some applications I have that also use eSignal are registered in the esignal-DataManager as TWO 'users', instead of the 'expected' ONE user. I am limitead to a total of 4 users on my one esignal account, so I like that MC is only 'one user' of esignal- datafeed.
In any case, even IF separate sockets are used by separate applications on the same machine, I don't think that must necessarily imply that eSignal's servers are responding equally fast to multiple 'requests' for the same data symbol (especially during very high tick volume, being delivered to thousands of esignal subscribers!).
I have a question concerning 'time-stamps' for each tick. Are those time-stampls supplied by eSignal (or in the case of FX, by the individual 'contributors' for a specific symbol), OR are these time-stamps supplied by the MC-QM processing? If those time-stamps are supplied at the 'source', then it is theoritically possible to calculate the delay-lag by comparison to some 'atomic-clock' ticks available over the internet connection, right? IF we had the capability to monitor and measure the relative time-arrival of each tick relative to its origination-time-stamp then we could all probably know a lot more about what/where any lag is coming from, until then I would not discount eSignal's servers as being a 'problem'.