Can ya speed up 6.0?

[WhoLovesYa]

Originally posted by hardtaill
The Short Interest is a little newer than that, as I check it againtst free sites from time to time.

It's a nice program.

here is a link from NASDAQ for CFC which obviously has had an increasing short interest - It is for settlement date of Nov 15th. It shows SI at 112M while QC shows 25M which is what it was on Feb 15th - you need better free sites .

http://www.nasdaq.com/asp/quotes_full.asp?mode=&kind=shortint&symbol=etfc&symbol=CFC&symbol=INTC&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&FormType=&mkttype=&pathname=&page=short&selected=CFC

If someone from e-signal wants to get me an e-mail address I will forward them 2 workspaces I have - the one I run in 5.1 that I have stripped down in anticipation of moving to 6. that runs just fine except for the things they have decided to stop updating

I can also send the even further stripped down version that I have manually converted index symbols, removed some lists and charts etc etc that still doesnt run in 6.0 when market is open.

Don't get me wrong - from what I see in off hours 6.0 looks like a good program. But and this has ALWAYS been the big but with QC, if it doesnt run correctly real time - what good is it to me?

Which will lead to the usual disclaimer, great program if you can get it to work when you need it.

[hardtaill]

WhoLovesYa,

Thanks for the update on the Short Interest. In checking other securities, I see that they're all over the map in QC 5.1. Some are Feb and some are Sept. Thanks for the heads-up.

6.0 Quality:

I've loaded six studies onto all 12 charts in my workspace.

1. Autowave.
2. Bollinger Band.
3. Donchian Channel.
4. Keltner Channel.
5. Moving Average.
6. Volume At Price.

I'm also runing 5.1 at the same time. The symbols in 6.0 are snapping into all 12 charts within 2 or 3 seconds. Any lag-time change is unnoticable. I've got a load of 455 symbols on 6.0. The 5.1 is also changing symbols very quickly.

My 1.1ghz and 3.2ghz are both "off-the-shelf" with no overclocking and are completely OEM, but, I keep all my ports closed exept for what's necessary and both machines are completely free of any unwanted viruses or trojans. I'm behind a firewall on both laptops. 6.0 is working perfectly from where I sit.

'Tail.

[JayF]

Undoubtedly, there's CPU and memory issues for many folks on QCharts 6.0; we've seen them here on the forums, and I've received many private emails on the subject into our suggestion box. It's true that some users are not having problems, while others are, and it's almost always related to usage patterns and the content of the workspaces being used compared to the system the workspace is being used on.

One of our main focuses on QCharts 6.1 is to increase performance on the CPU side and improve memory handling.

Many of the emails that have come into our suggestion box has users that were confused by the recent notice sent to all users. Some were under the belief that QCharts 5.1 was to stop working on December 28th altogether. I just want to clearly state that the Continuum servers are not going away at the end of this year. The Santa Clara server farm (abbreviated with a *.sc8.* in the server names) will remain up after the new year and through at least the end of March, 2008.

Our plan is to try to get QCharts 6 to where QCharts 5.1 is in terms of speed, reliability and content, all the while moving to the eSignal network. If we can exceed these goals, all the better. While we can't guarentee that 100% of QCharts 5.1 will make it in before the Continuum shutdown, that is our goal.

We want to work with the QCharts Community to determine when "we're there". We recognize that each user has a unique way of using QCharts, it's important to us to get a broad set of beta testers. We hope many of you here, will continue to help with our goal of making QCharts 6 the best it can be.

[rigeco]

Originally posted by JayF
We want to work with the QCharts Community to determine when "we're there". We recognize that each user has a unique way of using QCharts, it's important to us to get a broad set of beta testers. We hope many of you here, will continue to help with our goal of making QCharts 6 the best it can be.

Good enough for me. Thanks Jay.

If there's anything specific us users out here "in the field" can do I'll be happy to pitch in.

[mjenk]

Thanks Jay look forward to it.

[trader_phil]

QC 6 Features & Performance

Originally posted by JayF
Our plan is to try to get QCharts 6 to where QCharts 5.1 is in terms of speed, reliability and content, all the while moving to the eSignal network. If we can exceed these goals, all the better. While we can't guarentee that 100% of QCharts 5.1 will make it in before the Continuum shutdown, that is our goal.

We want to work with the QCharts Community to determine when "we're there". We recognize that each user has a unique way of using QCharts, it's important to us to get a broad set of beta testers. We hope many of you here, will continue to help with our goal of making QCharts 6 the best it can be. [/B]

First, let me say I have been using QC5 for over a year and I think QC6 looks and feels more responsive on the interface and that I have no issue with local resource consumption - CPU & memory seem fine - I have left it running for extended periods and watched its memory footprint grow slightly and shrink noticeably over time (yet shrink, on its own) and never had a CPU utilization issue.

I only have 3 concerns with QC6/eSignal at the moment:

1. Performance (see details below)
2. Feature Loss (Autowave removed)
3. New Restriction (symbol count limits)

While I realize the last 2 can be resolved by upgrading to QC Plus, I find it insulting to call QC6 an upgrade when the only change is I have to "upgrade" my service (paying more) to get what I had with QC5/quote.com - so it appears to be an upgrade for eSignal revenue more than anything else... at least for my use.

As for performance, it seems the issue lies with the data feed servers - to perform the same task QC6 requires 2X the raw data of QC5 to be moved to QCharts, the new servers provide it at a much reduced bandwidth and therefore take much longer to complete chart builds. Additionally, after viewing several charts if I return to an index it rebuilds again like it never downloaded any data. The biggest delays appear in constructing moving averages on charts that have data intervals shorter than daily.

Here is an objective measure of performing the same tasks in both QC5 and QC6 and you can see the dramatic differences clearly:

Performance Impact

QCharts 6 is MUCH slower, not so much the application itself but how it retrieves data or the way its feed servers are “throttled”. I ran tests using the same charting setup in both versions with the same symbols on the same computer (one at a time).

Basically it took 5.5 times as long to perform the same task in QC 6 as it did in CQC 5 – almost all of the delay seems to come from 3 areas (which are likely inter-related):

1. QC 6 required 2.2 times the data download as QC 5 required to produce the same charts
2. QC 6 had very significant delays in producing moving average lines on the charts with shorter than daily data intervals
3. QC 6 had much slower data transfer rates than QC 5


I used a communications metering application as I ran through identical tasks with as close to identical setups as possible in both QC 5 & QC 6 including selecting the same servers (though I am not sure that has the same effect in both versions)– here are the objective, empirical results which are repeatable:


QCharts 5.1 – scan 32 Symbols, 5 Charts per Symbol

DU Meter Stopwatch - #1
Start time 12/26/2007 1:27:35 PM
Stop time 12/26/2007 1:30:14 PM
Elapsed time 2 min 38.3 sec
Incoming Outgoing
------------------------------------ ---------------- ----------------
Total of data transferred 17.0 MB 416.3 KB
Maximum transfer rate 5.1 Mbps 96.5 kbps
Average transfer rate 903.4 kbps 21.5 kbps


QCharts 6.0.1.2 – scan 32 Symbols, 5 Charts per Symbol

DU Meter Stopwatch - #2
Start time 12/26/2007 1:33:59 PM
Stop time 12/26/2007 1:48:34 PM
Elapsed time 14 min 34.1 sec
Incoming Outgoing
------------------------------------ ---------------- ----------------
Total of data transferred 38.1 MB 1.5 MB
Maximum transfer rate 1.1 Mbps 55.9 kbps
Average transfer rate 365.2 kbps 14.6 kbps



My great dissatisfaction with the move to QC 6 is not a subjective issue of what I like nor an unwillingness to change – I had actually looked forward to QC 6.

But, your current implementation is unusable as it would cost me many extra hours each week than it does now on QC 5 – and I’d have to pay over 20% more to get the same features I had with QC5 though I'll get much slower service with QC6.

That is not an acceptable “upgrade” – it is a significant deterrent to use your new version - I'd really like to see this fixed.

I believe the issue lies not with the application itself but with the communication manager and backend servers (I've been a server infrastructure expert for 18 years) – either your infrastructure is significantly undersized or you are intentionally throttling bandwidth. It may be an application architecture issue in how communications are structured but since it is not straining my system resources (CPU / Mem/ Bandwidth) it is likely a server side issue.

[hardtaill]

trader_phil,

Thank you for your input. I'm not finding QC6 to be of any concern in delays as there isn't much. Slightly slower, but insignificant. The increase in cost is also acceptable to most of us because the accuracy of all data that we experience on QC6 is appreciated. QC5 had some real problems on the old servers and were not nearly correct until about midnight on each trading day. I believe any CPU or delay problems that most are experiencing will be corrected soon.

Thank you for running your tests. Some of us are not experiencing any delays during the trading day even with high symbol counts and multiple charts. Even 1.1ghz machines are doing quite well.

'Tail.

[Larry Marchman]

'Tail,

Awhile back you sent me your 4x3 workspace. I reported back that I also didn't have a problem running your workspace in 6.0 due to it's incurring a light load. Reference Post 106413 10-21-2007 10:59pm

http://forum.esignalcentral.com/showthread.php?s=&postid=106413&highlight=4x3#post106413

I can't find the workspace now. Apologies. Could you please send it again so that I can deconstruct in detail just why it creates such a light load.

Of course, those of us that see significant loads normally, as a matter of course with 5.1 due to larger more complex workspaces are having real issues with 6.0.

LAM
[email protected]

[hardtaill]

Larry,

I've sent you the two workspaces again to your email, 4x3 and wide, which are pretty aggressive. The option laden one actually takes a little more CPU than the multiple portfolios with securities.
They're both pretty aggressive.
Following are the two screenshots as well again:

http://forum.esignalcentral.com/showthread.php?s=&threadid=24277

http://forum.esignalcentral.com/showthread.php?s=&threadid=24277&perpage=20&pagenumber=2

As you can tell by the yellow highlights the data is real time.

[Larry Marchman]

'Tail, and other's following this thread...

I had a chance to load your 4x3 into 6.0.1.2 for awhile Thurs and Friday afternoons, going into the close. I saw the same as previously reported to you in another thread last October. And that is that your workspace just doesn't create that much load due to it's heavy bias toward Options. Your laptop's single screen workspace is not aggressive, and touting the symbol count is misleading, to say the least. After my signature below is a breakdown of the workspace. It should be obvious from the numbers why it doesn't create that much of a load, why symbol count is not a de facto definition of aggressive.

Look, here's the deal. This stuff about your box and your workspace is moot, is irrelevant, and has nothing to say technically about the 6.0 vs 5.1 %CPU issue. I, or anyone can build a workspace under 6.0 that will work in the sense that it will not overwhelm our respective boxes regarding %CPU utilization. But, like, ya know...so what? Big deal. This has nothing to do with the 6.0 problems that Quote.com has fully acknowledged regarding %CPU utilization. So you, or me, or anyone responding that all is swell and well "for us" in response to a user that has concerns regarding %CPU would be wrongheaded. And downright disingenuous if said response implied that something was wrong with the user if they are having issues and we are not. A person that has a unique workspace that doesn't bring that individual's unique and specific box to it's knees is just that, and only that, and has nothing to do with another person's experience, another person's box and unique workspace. Apples&Oranges.

So, one more time, for the umpteenth time, here's the issue.
I'll just paste in a paragraph from a previous post in this thread.

--------- paste from Post109033 12-18-2007 11:21 PM (slightly edited) --------------
"Other folks have more complex and more demanding workspaces and multiple monitors that already create a significant load under 5.1. Then with the greater %CPU hit(1) in 6.0 vs 5.1 (a factor more than some may realize), they may have very real and legitimate %CPU issues trying to run that same workspace in 6.0. As a quick example, if a user experiences a 20% CPU hit in 5.1, and the ratio of QC6 vs QC5 is 5X more %CPU (a lowball figure here), then the math is simple...5 X 20% equals 100% pegged.

(1) Some of the hit is legit...a greater number of ticks in the eSignal feed to process requiring more %CPU. But an equally, and perhaps larger hit is processing inefficiencies. And here's hoping that's the highest priority of the good folks in development."
-------------------------- end paste --------------------------------------------------------------

If the user's 5.1 production workspace manifests %CPU issues with 6.0, then the user will have to cut down the demand that the workspace generates to accommodate running it in 6.0. Or the user could opt for another box with more horsepower.

One last comment here that will probably push this post into tedious territory...
I understand and accept that adjustments may have to be made to accommodate for the higher number of ticks in the eSignal feed. Fair enough. I've made those adjustments while running 5.1 under a feed with ticks equivalent to eSignal, namely the IP4 feed [SClara10 and 11..a fatter pipe from Comstock], making the cuts with the result being an acceptable universe of data in the workspace. I would be good to go with that "tick adjusted" workspace on my current box running under 6.0 if 6.0 processed the workspace as efficiently as 5.1. But alas, that tick adjusted workspace will not run under 6.0 without pegging my box. Reason being the aforementioned significant processing inefficiencies that add %CPU way beyond the %CPU hit due to an increased #ticks. So, I'm holding off for now on laying out $$$ for another box, hoping that soon 6.0/6.1 will process my tick adjusted workspace as efficiently as 5.1.
[note: Running on IP4 can be a trying experience due to frequent server queuing. It took a thoughtful, time consuming and concerted effort over time to make a "fair" adjustment to my 5.1 production workspace, only measuring and adjusting when certain I was getting a full tick flow from those servers. fwiw, to further complicate a quest for apples-to-apples tweaking and a true determination of processing inefficiencies, there are more ticks in the IP4 feed than the eSignal feed due to eSignal being a BBid/BAsk only feed, but that would be another topic.]

I'm rooting for 6.1 to be as useful as 5.1 has been for me all these many years.

LAM

***********************************************
Deconstruction of the 4x3 workspace.
All numbers from Friday PM 20071228, after market close.
The tick(1) numbers represent a full days worth.

Symbol Count by category:
50 ...... Options - Hot List in Quotesheet - US Options #Calls (2)
314 .... Options - Quotesheet - all syms are RIMM Options
23 ...... Stocks/Futs - Quotesheet + 7 Fixed-Sym-Red 10min charts
8 ........ Indexes - Quotesheet
394 ..... Total Syms (395 -1 dup in HotList and RIMM QS)

21,694 ....Total Tick volume of all Option syms (363 of the 394 syms).
Compare with
52,370 ....Tick volume for a single example stock - QQQQ

Regarding the RIMM Quotesheet of 314 syms
3,743 ..... Total #ticks for 314 syms for the day.
279 of those syms had #ticks ranging from 0 thru 10

(1) Tick volume is a better measure of load(%cpu) than Volume.
(2) True, there is a refresh every 30sec of HotLists. So these numbers
are of one set. The nature of the HotList though is a similar mix each
refresh.
***********************************************

[hardtaill]

Larry,

The only way we're going to get to the bottom of this, especially since one of the workspaces I sent you has absolutely NO OPTIONS at all, is to send me YOUR workspace. I'm completley suprised that you didn't even try the workspace with 10 NON-OPTION portfolios and 12 charts ranging from 10 minutes to monthly. Larry, why didn't you try that one? It's rather interesting that you failed to do this. Quoting previous posts gains you nothing in finding a solution to the problem of running an aggressive 6.0 workspace.

Is there something wrong with running 10 NON-OPTION portfolios and 12 CHARTS? Who among us wouldn't want to be abe to do this? I do, and enjoy it very much.

Now, to be perfectly honest, Larry, you need to try the NON-OPTION workspace that I sent you and see if you can run it during market hours. In the event that you've lost that one, I am emailing you that one again. It's in widescreen format, but I'm sure you can squeese it down to your 4x3.

Please send me YOUR workspace that you are having trouble running on 6.0, and make it the version which is NOT throttled. Send me the one you love to run on 5.1.

And while I'm at it, and since I'm feeling so robust this holiday weekend, I'm extending an invitation to ALL 6.0 users to send me their workspaces for evalualtion. I will run them during market hours on Monday and Wednesday of the coming week. Please don't send me your throttled versions, but rather send me the ones that you like to run on 5.1 and after limiting the symbols to 500, I'll put them in play during market hours.

Please email them to [email protected] The hartaill has two "ll"s and no "d".

Looking forward to seeing how they function.

Thank you, and have great holiday,

'Tail.

P.S.

Larry, don't forget to send me your's, either by my usual email or to [email protected]. Either way is fine. Please, no throttled versions.

'Tail.

[Larry Marchman]

The only way we're going to get to the bottom of this... ~'Tail

<sigh>
You just don't get it. That the issue is not about you, but rather it's about the relative difference in %CPU incurred running the same workspace on the same computer under 6.0 vs 5.1.

You can't run my workspace. It runs integrated with the MBT Trading Platform(1).

What would it prove, what would it mean were I to run your Wide on my box, or any other person's workspace. My box is not your box. You run the Wide on your 3.2Ghz laptop. I don't have a 3.2Ghz machine. Apples and Oranges. Meaningless.

1. Do you deny that you have seen a difference of "at least" a ratio of 5 times the %CPU between 5.1 and 6.0 running the same workspace on the same box?

2. Do you deny that there are users that experience, as a matter of course, 20%CPU for the 5.1 QCharts task running their (not yours) workspace on their (not yours) computer?

3. Do you deny that 5 times 20 equals 100?

I'm done, I give. I don't have the skill to "get to the bottom of this". With "this" being your inability to "get it".

LAM
(1) For you MBT'ers that may be curious, I've hacked 6.0 to run integrated by fooling the MBT platform and permissioning process to think it's dealing with 5.1.

[hardtaill]

Larry,

Go ahead and run my Widescreen workspace without options on Monday. In the mean time, it's comical that you won't give me your 5.1 workspace. Seems suspicious. Oh, and don't foreget to let us all know how my security-heavy workspace functions on your box.

1. I do not deny there is a difference.

2. I do not deny the 20% difference.

3. I do not deny that 5 time 20 equals 100.

Again, email me your 5.1 version and I'll run it on 6.0. If not, then I will think something else is up. Any other 6.0 users who want me to run your 5.1 on 6.0 just email me at [email protected].

Both my option-heavy and my security-heavy workspaces run just fine on 6.0 . The program works just fine from where I sit. And, Larry, you don't need a 3.2 as I've posted before.

Let's see if we can solve a few problems here instead of trying to play one-upsman.

'Tail.

[Larry Marchman]

'Tail,

<sigh>
You just don't get it.

Running one person's workspace built on one box on another person's box does not prove or mean anything within the context of 6.0 vs 5.1 %CPU differences experienced when running the same workspace on the same box. It's wasted and futile effort, and I don't care to waste anymore of my time.

There's nothing suspicious here. It's just that you don't appreciate what MBT-QCharts integration means. Not to mention, again, the apples and oranges nature of the exercise. What if I did send you a workspace and it ran just fine on your box. So what? Doesn't mean a thing, doesn't change the fact that that workspace on "my" box works on 5.1, but due to %CPU hits in 6.0 it doesn't work. This isn't just me sharing my experience. I assure you I've worked with other's off-list to see if they also see the same X-factors I'm seeing...that is at least a 5X ratio. And that's a low ball figure for the purpose of a simple example. And goodness knows how many other folks have expressed the same issue in posts.

The notion of "one-upmanship" never crossed my mind. I'm just sharing actual factual info regarding the %CPU issue.

Why not just put up a workspace on your box that hits 20% sustained under 5.1 and then notice the hit under 6.0. You admit to the 5X ratio.

5 x 20% = 100% pegged. That's what people experience, period. Sharing workspaces won't change that, and is irrelevant to that.

LAM

[hardtaill]

"What if I did send you a workspace and it ran just fine on your box. So what? Doesn't mean a thing, doesn't change the fact that that workspace on "my" box works on 5.1, but due to %CPU hits in 6.0 it doesn't work."
....................................
................................................

Well, now, Larry,

If your 5.1 works on my 6.0 then maybe we can fix your box. The %CPU hits that I get should be just like yours. I'll even run you 5.1 on my 1.3ghz and, most likely, will run just fine in 6.0.

"Sharing workspaces won't change that, and is irrelevant to that."
..........................
.....................................

No, it is not irrelevant, Larry. If 10 security-laden portfolios and 12 charts run on my box, it should run on yours and everyone elses. Period.

Larry, just send me your 5.1, that you say is a really good workspace and brings your computer to its knees in 6.0, and I'll run it in 6.0. Period.

Wow! Wasn't that easy?

'Tail.