Anyone else having problems: eSignal SLOW speed loading data?

[ezreddy]

What is the current status on this? I have not seen any comments from moderators recently. Thanks.

[Patch227]

Originally posted by ezreddy
What is the current status on this? I have not seen any comments from moderators recently. Thanks.

Yes I agree

Once again I am having problems with us equities despite being connected to the trades only server.

[eSignal_AveryH]

Hi Patch,
Can you PM your username so that we can check the servers you're connected to.

AveryH
eSignal Support

[ezreddy]

What is the current status on this? I have not seen any comments from moderators recently. Thanks.

[ScottJ]

Update:

We've continued to make significant improvements to our overall network infrastructure and the results appear very positive compared to 3 weeks ago. We are pushing out more data as a result of our enhancements so that will continue to put more pressure on the performance of your desktop to keep up with the "spikes" in data rates.

If you are still seeing delays, please let us know.

Thanks.

[eSignal_AveryH]

Hi Patch,
Sorry for the delay in answering we wanted to do some through checks before replying.

I have done continuous monitoring of the servers you've been connecting to and testing different equity instruments on those servers. Other then a 2 second delay on AAPL on Tuesday which corrected itself rather quickly we have not seen any other delays.

If you continue to see delays from your side please contact Technical Support so that we can do proper troubleshooting for see what the problem is.



AveryH
eSignal Support

[Lisa23]

I run a very simple page, and am using the old version (8.0) and yet today, which is not a fast pace day, I am getting lags of about 20-30s on both the stock charts and a tick/trin chart. Needless to say, when that happens, Esignal is worthless to make decisions on entries or exits.

When is this going to be fixed? I have 2G memory and a fast processor, so this should not be happening. At some point I can just use discount broker charts for analysis and watch my tape for entries and exits and save $$.

[Lisa23]

I should add I usually trade the Q which is not subject to the volatility of an AAPL.

[eSignal_AveryH]

Hi Lisa23,

Though we have admitted to delays in the early part of March, the last few weeks have shown that the corrections we’ve made are working. With some of the new implementation we now can see when records are not making it the user’s desktop. In your case we see that you’ve dropped just over 2million records over 3 hours that you’ve been connected. This could be happening anywhere along the line of Internet connectivity and or at the desktop level. I see you have a good machine but depending on what other applications you have running this can reduce the amount of memory you have left for eSignal. Like the memory, your Internet Connection also has to be shared, and if you’re requesting too much than your alloted bandwidth can handle, it’s possible that packets/records may be lost. For additional reference regarding overall performance, please see the following KB article.

http://kb.esignalcentral.com/article...ticle=1639&p=1

[Lisa23]

My other data feed from IB does not appear to be delayed. I purposely close all browsers, etc, that might possibly take up memory. I don't run any other applications to take up processor speed. I am on a cable connection, and am the only one on it right now so that is not the issue unless people need T1 lines to use Esignal which I doubt. I have also been told by your Tech support that memory is not that important, and 2G is plenty (I should hope so.)

When you say "dropped" what do you mean?

Since others complained today, I must assume it is not my machine. If it was my machine, it would not be intermittant.

Please work on your end instead of constantly telling your customers it is their fault.

[gspiker]

Just FYI to people on this. I have found that I can get better performance connecting to some set of eSignal servers rather than others.

By using tracert and starting and killing eSignal so that I'm occationally redirected to new server, I have found a set of servers that seem to work well for me.

In my case, the cause for the poorer performance does seem to be the network...some paths have many more hops and much longer delays (including many timeouts at some hops ).

It would be nice if eSignal provided either a way for a user to specify what servers they want to use, or an automated feature that would monitor the amount of dropped packets due to network path issues and reroute automatically. This last option would work better for users and for eSignal, since I bet they do some sort of load balancing and they could make an automatic reroute work in conjunction with their load balancing efforts.

Now even with a good path, tick charts are still a problem, so there are other issues...but trial and error tracing routes has worked for me in getting better performance.

Garth

[Dave180]

Garth,
Have you tried netstat to check the list connections to eSignal servers? That is it shows a list of connections from your PC to the outside world, the eSignal ones are easily identifiable. But there again how do you know what to tracert if you don't. BTW, you have to use "netstat -n" to get the actual IPs, as the names displayed otherwise do not forward resolve to IPs (they do reverse lookup), and the final address does not usually reply (that must cut their load a lot!). It is common for busy routers to drop echo packets, so getting a loss with tracert does not prove that data is being lost, although at best the routers are busy enough to do the drop.

Could you share some tracerts? I'm disadvantaged by being across the pond, but find that the routes are consistent at around 110-120 rtt, that aspect does not seem to affect the problems. Although there are sveral different connections they all seem to be handled by the same route / location.

I am recording (with a monitor prog which monitors the Data Manager Symbol Monitor rather than eSignal or other apps) the ongoing delays in the ES feed. Today was better than most with a single delay period over 3 seconds that maxed at 4.7 seconds and lasted for 8 seconds, however post ISM was a disaster. If I count the delays associated with each sample I find the most (mode) samples get delivered with a delay of around 350-450 ms (of which 60 or so is the internet delivery).

It would seem impossible to reconcile the delays recorded by users and the improvements claimed by eSignal, it is difficult to see how the differences can be so big. My machine's cores do not seem to be maxed out (although I don't get to check it each time there is a data delay), but it certainly is quite busy.

Dave

[FloridaDude]

Originally posted by Lisa23
My other data feed from IB does not appear to be delayed. I purposely close all browsers, etc, that might possibly take up memory. I don't run any other applications to take up processor speed. I am on a cable connection, and am the only one on it right now so that is not the issue unless people need T1 lines to use Esignal which I doubt. I have also been told by your Tech support that memory is not that important, and 2G is plenty (I should hope so.)

When you say "dropped" what do you mean?

Since others complained today, I must assume it is not my machine. If it was my machine, it would not be intermittant.

Please work on your end instead of constantly telling your customers it is their fault.

I hear you. I am so sick of esignal blaming on their customer's computers and internet connections that I could barf. I have a 10Mbps cable connection that is SCREAMING fast. My computer has 2 Gigs of memory, Dual-core Opteron 185 processor (2.6Ghz), 4 hard drive RAID 0+1, etc. etc.

Also, they are confusing "dropped packets" with "delayed data", there's a BIG difference. I'm getting the packets...the problem is that the data in those packets is lagging the market by several seconds or more.

[Lisa23]

I agree.

I appreciate the techno-geek information, that may be a bit beyond me.

I have had packet loss problems before (about 5 yrs ago) but it was connected with the big trunk line in Chicago or something and it was different than this.

As you said, the data is not missing, it is delayed. I can watch my IB tape and then I have to wait for Esignal to catch up so I can capture my screen for my journal.

This am I also had an issue with NO DATA, so I did close and reopen. I think there are definate issues with servers. A corporate server I work on sometimes actually kicks people off when it has too many rather than re-route them, I wonder if that is what is happening.

I already upgraded my memory at the suggestion of Esignal (which, evidently, doesn't really make a difference) and I am not going to go buy a new computer so they can avoid the issue.

I'm glad to hear you have a quad core 2.6 and you still have issues. The one really nice tech support guy I talked with confirmed that with how I use the program, my system is more than adequate. I am running the 8.0 anyway, which is supposed to be much less of a system hog, but that change made NO difference, surprisingly (or not, if you assume it is not my system!).

[demarcog]

If TCP-IP (network records containing the data transfered and related network information) packets are being dropped because of a bandwidth, routing, or hardware problem this occurs on a system wide basis, ie, all network related applications are effected, usually equally.

If one network application, eSignal is experiencing a problem but all others, ie., IB is not, then this eliminates the "network" as the source of the problem, it is application problem not a network problem.