15S Interval Performance Issue

[sr5566sss]

Hello,

I have an application that uses numerous charts to make trading decisions and has worked great with minute bars. Today, I added a "15S" (15 second I believe) chart (in memory) with 10 bars requested: the call I'm making is basically as follows - RequestHistory("YM", "15S", eSignal.barType.btBARS, "10", 0, 0).

Doing so causes severe stress on my application which up to this point works without incident at about 5-12% CPU Usage. When this call is made, the processor jumps and formerly benign tasks such as viewing the 10 bars in a textbox now freeze the interface.

Incidentally, I notice that I receive all the bars since midnight (500 or so....) instead of just the 10 I requested. This is certainly part of the problem. Note: for all my minute bar requests, I get exactly what I ask for.

Thoughts? Thanks in advance.

Jason

[DionLoy]

15S will cause a request for tick data. Tick data resolution is only on a day by day basis, so you will get it from midnight instead of just the ten bars that you had asked for. The tick data collection, download and processing is a _significant_ hit on the CPU due to the amount of data present.

[sr5566sss]

Thanks for the reply. I've read in numerous places that 15 seconds charts would not only function just like 1 minute charts, for instance, but also be called via interval terms such as "15S". Why would this process as tick data? I'm alittle confused seeing as how this is just a higher time resolution with all other things being equal. I believe there is one other post dealing with a person's questions on second charts and the technical contact responded that the charts/bars requested would be exactly like 1 minute charts/bars except with a higher time resolution. There was nothing in the documentation that stated calling "15S" would result in tick data being sent - where can this be found in writting.

Im confused at this point.

Thanks,

Jason

[GenSpoo]

The servers don't store 15S bar data "pre-formed", so they must be built from tick data, which is done on the client side. One minute bars are (I assume) stored in that form on the server side already, so a request for them occurs much quicker as nothing needs to be built.

15S bars do get sent to the OnBarsChanged and OnBarsReceived exactly like 1 minute bars. The only difference is the behind the scenes way they are created.

Cheers... George

[Roland B]

Dear ss5566sss

I will not take the time to attempt calculating all the combinations possible from using "T", "V", "P" or "S" with their respective quantifiers when making a RequestHistory call. It will go in the millions. NO WAY they can keep this on their hard disks at eSignal, for each and every security out there. 1-min bars on the other hand are a familiar feature that requires little bandwidth.

Your problem might be solved though. If you issue a call in the middle of the main trading session, your CPU will get stressed to maximum warp since the client will have to receive all "bars" since midnight. These are coming in at full speed. Once you're client is past the "historic" bars (i.e. up to current time), activity will slow down. Unless you are looking at a bunch of highly active data (such as ETFs), your system should have no problem dealing with "15S" if you preload them as early as possible, preferably when the session starts and use them on an as-needed basis. As DionLoy has pointed out there is no way limiting the timespan of tick data below the current day.

(Your user name will have me look out for you in Star Wars Episode III.)

[Guest]

You can also just request streaming quotes and create the 15 second bars in your application.