Sub-minute interval chart CPU efficiency

[bfry5282]

Now that 7.4 is released, I would like to resurrect this topic of excessive CPU consumption for sub-minute interval charting (not tick charts, which I avoid). I know this is a complex issue, but let me outline why it's a problem for me, what I'm trying to do about it, and where I feel the problem lies in the winros/winsig interaction. Also, it's not restricted to 7.4, but I've had this issue in previous releases as well.

I trade only 1 single active stock -- Intel (INTC). I run charts which are down to the level of 2s (two seconds intervals), but I never attempt to run T (tick) resolution charts. I know that these are "tick derivative" interval calculations, and perhaps therein lies the clue that winsig is not handling this as efficiently as it could. I know 2 seconds sounds extreme, but that's not really the issue, I'm pretty sure...

In my own custom EFS formulae, I use every trick in the book to lower cpu usage, and I am a very good performance programmer. I always use setComputeOnClose() hoping to avoid intra-interval callbacks, when not necessary. The problem is not in the EFS formulas, I'm sure. It is in the way the winsig.exe *client* process handles sub-minute "tick derivative" interval data.

From the behavior, either winsig.exe is "polling" excessively (pulling data), or it is getting "jammed up" with callbacks initiated by the winros communication mechanism. This appears to become "pathological" at a certain frequency, and the system backs up, unable to respond to the desired throughput.

The winros/winsig interaction involves interprocess communication, obviously, and I think this may be part of the problem. I set my XP Pro system to schedule short quanta for each process, to encourage fast and frequent context switching. Even in periods of very low trade volume (a few trades per second), winsig.exe can remain at 100% cpu consumption, and there simply is no good reason for this. Having written lots of software myself, I'm not bitching, but just trying to point the way toward a solution to this CPU issue, which several users have remarked upon. All software has loading issues, especially when not specifically designed to handle maximum loads gracefully.

Anyway, although I can use eSignal for wonderful analysis, I cannot rely upon it for the latest price information, especially during active volume periods, due to winsig.exe process CPU saturation. (2.5ghz processor, 1.5gb ram) Often, very significant delays (maybe even up to 30 seconds) appear, when this interprocess communication and the callbacks from winros to winsig run into a "log jam". Sometimes, winsig never catches up, and the process has to be killed. I use RealTick as an Order Entry platform, and am forced to rely on its graphics for the latest information, since it never falls behind the tape. The problem is that RealTick's charting is not even in the same league as eSignal's.

If this problem can be overcome, then I would consider some semi-automatic trading driven by eSignal. As it is now, I simply can't rely on it to "keep up" with an active stock, and I am convinced that there is a solution to this problem, but it would involve examining winsig.exe's response to incoming data, and nailing down where unnecessary cpu loops occur. I'd be very happy to beta test a proposed solution to this problem, which would make eSignal a even better product, incredible as it is already !

[WAVETRADER1]

I have the same problem.

This problem is serious. I have done everything I could think of
to offload the cpu , but winsig still crashes or freezes from overload of data.I can see the frustration of users and can tell
you it's not the hardware or OS. Esignal is in a class of it's own
with AGET nothing else is as good . If you could address this
in someway it would help me and other users who trade 24/7
immensly.

Thank You

WAVETRADER1

[JayF]

WaveTrader, since you are having a similar problem, could you do a quick comparison with the details bfry gave? Similar intervals? A handful of symbols? Powerhouse computer?

bfry5282, how many charts are being used? Have you tried running the EFS performance monitor? If so, what are those results? (Not to criticise or blame your custom EFS work, but instead to gather more information to pass along to the developers.)

Thanks all for helping.

[bfry5282]

Re: Reply to post 'Sub-minute interval chart CPU efficiency'

I've never used the EFS monitor, but will try and get some results. I don't
mind of you criticize my EFS programming, but it's fairly efficient, and I'm
hoping to get some clues from developers just why the winsig.exe client
appears to use so much CPU. I think the bottleneck is the interprocess
communication, and a high rate of callbacks to the client process. Also, it
may also be that data accumulates in the client as the day wears on, and
perhaps sifting through that information is an overhead. Any clues?


----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: Friday, August 29, 2003 10:45 AM
Subject: Reply to post 'Sub-minute interval chart CPU efficiency'


> Hello bfry5282,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

[bfry5282]

My EFS performance is efficient

OK, finally had time to run the EFS performance monitor. While my cpu sits continuously saturated running winsig.exe, with only moderate trading going on in my ONLY symbol INTC (Intel), it appears that my efs spends only about 0.12 msecs average time per call. Fastest average was 0.028 msecs and slowest was 0.21 msecs on about 1600 calls.

To me, that's efficient in the custom EFS (so my coding's OK), and the cpu time is being consumed in winsig.exe due to some unknown design flaw, IMHO. This renders eSignal just about useless to me, except for historical analysis. I rely upon RealTick's graphs for up to the tick information, as eSignal lags significantly, and its GUI is often unresponsive when saturated.

Charting is on 15s intervals and, as we know, any sub-minute charting suffers from this cpu problem. I'll probably have to restart the client, because I believe it may accumulate too much data to handle, although that can often result in minutes of delay while data is being loaded. This is just impractical for me, and I am reconsidering whether I shouldn't simply work off the RealTick charting altogether.

So, why can't someone tell me what is the most likely explanation, why winsig.exe is continuously consuming so much CPU for sub-minute charting? The problem is in the client code, which is unable to sustain the winros.exe callback rates in a moderate to slow paced INTC trading environment.

Again, the system is a 2.5ghz Pentium 4 single processor, with 1.5gb memory and no swap file configured at all. I updated the Appian Rushmore video drivers to latest version, and I run 3 of 4 monitors at high resolution, although I doubt that is where the problem arises.

[bfry5282]

winsig.exe client restart doesn't help

Just FYI, restarting the winsig.exe client doesn't help. I think winsig.exe needs to "yield" the cpu, since there appears to be no reason why it should "compute" so much when trading volume is light to moderate right now. I'm going to see whether I can get Windows XP Pro to pre-empt this application, and give it only a small quantum of compute time, in an effort to get an idea what the problem is here...

[JayF]

bfry, Wavetrader,

We acknowledge that clients are having eSignal CPU issues, and know we are trying to gather information linking the occurences to find the commonality.

Please also know that we suspect the number of affected clients is low. We have had only a handful of calls come into our phone queue, and only a few members on the forums reporting high CPU issues since the release of 7.4. We have been unable to duplicate this problem internally.

Below is a screenshot of my CPU usage between ~12:40-12:50 PT on a modest layout containing 2 Advanced Charts of ES futures (8 Advanced Get studies each), and a Quote Window with about 25 symbols. Just for reference, I'm running a P4 2.4 Ghz, 500Mb SDRam, Win XP SP1.

P.S. To further test, I will be re-running today through Tick Replay, and will be monitoring CPU closely.

[bfry5282]

One thing I think Wavetrader said was "long running" clients. I have noticed that, on my 15s charting, despite my trying a time template of "last n bars" on a candlestick chart, that in the afternoon the saturation of cpu is continuous. In the morning, it's intermittent. Restarting the client does not improve the situation.

So the client (winsig.exe) needs a way of getting rid of accumulating data perhaps, as I'm personally usually interested only in the last hour or two of charting and time templates don't appear to work to limit the client's (winsig.exe) workload as they should for 15s interval style charting. I suspect also that there's some considerable inefficiency with multiple callbacks from winros (Turbofeed) into the client, causing a "pathological" saturation condition. A callback per tick is certainly not desirable, if that's the way it's done. Also, I hope the winsig client is not "polling" in a cpu loop for data, which could also be an issue.

Optimization of tick bar consolidation in the winsig.exe client will be the key to responding to peak market conditions, and I hope you are able to isolate the problem with sub-minute charting. I volunteer to test any beta software you come up with, designed to address this performance issue.

[bfry5282]

cpu issues not limited to 7.4 release

I'd like to reiterate that I've always had CPU usage problems, and have completely given up with TICK charting, backing off now to 15s charts which I know are "tick derivative" in nature because they are sub-minute charts. This problem is not limited to the 7.4 release from my perspective. I have always noticed that winsig.exe appears to be "looping" or "polling". When I used InvestorRT, it was never a cpu hog, and it responded to callbacks from your OEM access module to the TurboFeed process. So winsig.exe was saturating the cpu, and InvestorRT was responding correctly, driven only by callbacks. This should not be a difficult software issue to isolate.

Another thing is that your callbacks may also be multi-threaded, in the sense that each callback might previously have waited for complete return from the client, but now you may be firing callbacks into the client with a separate thread per callback. I'm just speculating here, but that can require mutex thread synchronization code, etc, depending on how multiple threads share common resources. I'm a Java thread programmer, and I know many of the issues which may be involved here, although I can't say how winsig.exe/winros.exe handle their mutual interactions.

Just some thoughts, but surely the sub-minute cpu usage can be understood by code inspection alone! Does the client poll? Are multiple threads being used (one per callback), etc. The basic design, IMHO, has a problem which results in an overall client cpu runaway problem during times when the underlying symbol is relatively quiet in terms of trade volume.

Try looking at INTC all day long with a 5s chart, and perhaps you will begin to see the problem. There is no way that my esignal installation will keep up with INTC at a typical active open, so I have to rely entirely on my RealTick charting for up to the tick data.

[JayF]

bfry,

Could you send me a sample eSignal Page that you have CPU issues with? I really do want to duplicate this here, so we can say, "Yep, it's our issue" or "Nope, it's a local issue". Feel free to email me at [email protected]

I look forward to your email.

[bfry5282]

line list the problem

A humble retraction. Jay discovered that there were 200 line segments in the chart, and that removing them dropped the cpu down to normal levels. OK, "mea culpa", but I had no idea line processing could possibly be that cpu intensive, but it's good to know and try to avoid. Personally, I love to annotate charts, but I'll be careful in future. For now, problem greatly alleviated, and I'm looking forward to evaluating the performance under load.