Trouble with slow quotes/chart retrievals

[clearpicks]

Yes. Loading 60 min charts is slow.

Originally posted by aerbis
I agree. I'll have to get another data providor if the speed does not increase. Esignal seems real slow the last month. So slow, I don't even like changing symbols because it takes over 1-1/2 minutes to load charts with only 2 MA's and I have redundant high speed connections and I even tried at other locations with high speed access and I get the same slow chart response. Especially 60 min charts. Also, when I select a new symbol, some symbol names change while the chart is still the old symbol data and it finally changes after a while. What good is reliable data if it's old?

[aerbis]

Why should we constantly debug and tweak Esignal and our PC's to make Esignal run adequate when the software cost $1,500.00 - over $2 grand a year. For that price the software should run flawless. How could it be my machine or connection when I've tried from 3 different locations across the US on high performance graphics workstations and high speed connections and I get the same slow performance. And I only use Candles, Volume, MA's and Pivots. No magical EFS formulas or scripts to slow Esig down...

[WSHHMM]

almost three week at the market open, esignal is frozen.

really a good software.

restarted my computer and lose the save my page. what a shame for me.

[ScottJ]

WSHHMM,
Have you stepped through the various items in this FAQ? You seem to be reporting a new problem in pages not saving as well.? Is that correct? Perhaps it's time you work with Technical Support directly to help figure out what's going on with your system. You can call in or we can have someone call you.

aerbis,
Good troubleshooting is all about isolating the variables. The vast majority of our customers don't report issues with slow chart retrievals. We have customers all over the globe, using our systems to trade full-time. When a customer reports a problem that we can't identify as wide-spread, all we are left to do is isolate what variables may be in play in that particular situation. It sounds as if it may be time for you to work one-on-one with a technician as well. You can call in or we can have someone call you.

Thanks.

[ScottJ]

Just ran into some interesting user experiences on a competitor's message board. Best of all, they posted a couple of solutions that worked for them. Check this post out.

Thanks.

[ScottJ]

aerbis and clearpicks,

We have been researching precisely how our tick servers handle chart requests to help give us some more clues as to what may be going on for certain users. From the information we've gathered, there is some logic as to why 60 minute charts take longer than say a 1 minute or 5 minute chart.

When our tick servers respond back to chart requests, it builds the return segments one day at a time. Let's take an example like IBM.

If you request a 1 min chart, you'll get some 420 bars for one day and pretty much fill-up your screen. Depending on the time template applied and the # of bars requested, you'll get a good amount of data in each segment and fill in fairly quickly.

On the other hand, if you request a 60 min chart on IBM, you'll only get 7 bars per day (or per segment) so to get 300 bars, the system will make 43 individual requests for data segments (7 bars per day times 43 days equals 300+ bars ).

That's the primary reason longer intervals take more time to fill-in. Same would be true for 55 min bars or 120 min bars. The fewer bars that can fit into one day, the longer it will take to fill-in for multiple days or 300 bar requests.

Please try adjusting your time templates to limit the # of days or the # of bars and gauge how the speed of retrieval changes. I've been experimenting this afternoon and can really tell a difference as I adjust with these one-day segments in mind.

Down the road, we have plans to alter the way the tick server fulfills requests and to use size per segment (say 100kb) as the base and not a "day". This would greatly speed-up retrievals for longer time intervals.

Thanks.

[pj909]

Scott,
I've noticed slow loads on Daily charts also, especially after market close. Does the same logic apply?

[ScottJ]

Hi pj909,

Our history servers operate quite differently from our intraday servers so the same logic does not apply. I can't recall seeing any other users having difficulty with daily charts so you might experiment with the time templates you applying, double check your connection, etc.

Thanks.

[clearpicks]

Hi ScottJ,


I just read your post. Thanks for your reply and hopefullly you have find the true reason causing slow retrieving problem on 60min charts. Sending out one request for each day obviously is not a good design because much overhead is added due to network delay and responsing delay on the server side. I wish this bug can be fixed by the next release since this seems only an bug easy to fix.


Clearpicks

Originally posted by ScottJ
aerbis and clearpicks,

We have been researching precisely how our tick servers handle chart requests to help give us some more clues as to what may be going on for certain users. From the information we've gathered, there is some logic as to why 60 minute charts take longer than say a 1 minute or 5 minute chart.

When our tick servers respond back to chart requests, it builds the return segments one day at a time. Let's take an example like IBM.

If you request a 1 min chart, you'll get some 420 bars for one day and pretty much fill-up your screen. Depending on the time template applied and the # of bars requested, you'll get a good amount of data in each segment and fill in fairly quickly.

On the other hand, if you request a 60 min chart on IBM, you'll only get 7 bars per day (or per segment) so to get 300 bars, the system will make 43 individual requests for data segments (7 bars per day times 43 days equals 300+ bars ).

That's the primary reason longer intervals take more time to fill-in. Same would be true for 55 min bars or 120 min bars. The fewer bars that can fit into one day, the longer it will take to fill-in for multiple days or 300 bar requests.

Please try adjusting your time templates to limit the # of days or the # of bars and gauge how the speed of retrieval changes. I've been experimenting this afternoon and can really tell a difference as I adjust with these one-day segments in mind.

Down the road, we have plans to alter the way the tick server fulfills requests and to use size per segment (say 100kb) as the base and not a "day". This would greatly speed-up retrievals for longer time intervals.

Thanks.

[ScottJ]

Hi clearpicks,

You are right. Making requests one day at a time is not an optimal design. Our current tick server design dates all the way back to when we first released our internet based service. Back then, we only had 1 day's worth of data. Then it grew to 5, 10, 30, 60 and now 120 days. This was a logical design when we had only 1-5 days of data so in that sense, this is not a bug. The tick server needs to be redesigned and that project is already underway. It's no small task however so it'll be at least a few more months before it's put into production.

The main reason for posting the explanation was so customers could keep the design in mind when making server requests and to help explain why some customers felt our 60 mins charts we're slow, while others had no problems whatsoever. It all depends on what you're requesting and could be compounded by your connection ( i.e. if you are making 43 requests to the server, then an extra few hops or stalls in your ISP routing could make a huge difference ).

Thanks.

[aerbis]

Experiencing the same slow performance rendering charts. 60 min charts take over a 1 minute to load. I don't even like changing symbols since it takes so long to change. Again, only using 20 and 200 ma and vol. I even tried going from 4 monitors to 2 and the same slow performance on different machines. Also, most the time when I come back from lunch winsig.exe at 100% and nothing else running. I usually need to shut down and restart esig. Running 7.6 636a. Note: Running Dual INET connections and every other interent data app I run is super fast. I only have trouble with Esig but I guess it's just me.

[tradersaavy]

I use tick data all day long.

In the morning the charts from Esignal are sometimes more than 10+ seconds off. Can't trade tick charts like this.

In the afternoon they are about a second or 2 off, depending on volume (which shoudn't matter) which is ok, but of course it would be great for my IB platform and Esignal to coincide.

I have a 600 something processor and 256k memory.

Is it me or the server that provides tick data ?

[DuaneG]

Tradersavvy,

We aren't seeing any delays with tick data on this side. Based on the information you provided about your system, you may want to check out the minimum requirements needed to have eSignal run efficiently. As you are following tick charts on a regular basis, I would refer directly to the Power User requirements. This is very likely a CPU saturation issue as a 10 second delay is considerable.

[tradersaavy]

I am wondering if a non Esignal member has any insight on tick charts. Specifically, do you use tick charts without any problems and if so, what are your computer specs ?

I use only 1 tick chart, 1 interval chart and a time/sales window.

Thanks.

[eeminimee]

Hi tradersaavy,

I would switch from 133T to 89T for the symbols ES, YM, AB and NQ. Since I use the Woodies CCI layout, it does take a few seconds to load but after it gets loaded, the quotes are in sync with my broker. I do use J-Trader and I am using another computer to place my trades.

I have 1 tick interval chart, 3 min. 1 min, 13 min. chart. I have a quote window with around 15 symbols and a CME level II window. My specs for this PC:

Windows 2000
1 gig processor
256 mb ram

For my J-Trader platform, I use my laptop with a faster processor.

Windows XP
1.8 gig
712 mb ram

Most people don't use this setup, it's just that in case my eSignal crashes, my trading platform is not affected and I can still place trades.

Hope this helps.

-Me