CPU 80% at idle

I'm seeing my development session idling at 80% cpu. This is with nothing but
the system folder open. No other apps open and task manager shows dolphin.exe
taking all the CPU.

 I think it might be related to ActiveX. The reason is at some point I noticed
that the CPU would jump from < 10% to 60%  (and stay there) when
single-stepping over a call to IaXWinHostWindow>>createControlEx..  

At first I pursued this as a problem with the control. I confirmed that other
users did not see any jump in CPU. Also I was able to open the control at
times with no CPU jump.

In any case I have made sure that there are no longer any instances of any
controls open or instantiated in the image. I closed all windows with the
panic button. Nevertheless the system is just flatlining at 80% cpu. If I
click on 'exit dolphin' the CPU drops to 7%. Dismissing the dialog it's back
to 80%. After closing the image the cpu drops to 1%.

I'm not sure but I believe I saw this on D4 as well. Something in the Dolphn
process is revving the CPU ..

I have no idea how to track this one down.

alan r.

ps on w2k

"Alan Reider" <[hidden email]> wrote in message
news:[hidden email]...
> I'm seeing my development session idling at 80% cpu. This is with nothing
but
> the system folder open. No other apps open and task manager shows
dolphin.exe
> taking all the CPU.
>
>  I think it might be related to ActiveX. The reason is at some point I
noticed
> that the CPU would jump from < 10% to 60%  (and stay there) when
> single-stepping over a call to IaXWinHostWindow>>createControlEx..
>
> At first I pursued this as a problem with the control. I confirmed that
other
> users did not see any jump in CPU. Also I was able to open the control at
> times with no CPU jump.
>
> In any case I have made sure that there are no longer any instances of any
> controls open or instantiated in the image. I closed all windows with the
> panic button. Nevertheless the system is just flatlining at 80% cpu. If I
> click on 'exit dolphin' the CPU drops to 7%. Dismissing the dialog it's
back
> to 80%. After closing the image the cpu drops to 1%.
>
> I'm not sure but I believe I saw this on D4 as well. Something in the
Dolphn
> process is revving the CPU ..
>
> I have no idea how to track this one down.

You could start by telling us which Active-X control you are using :-)

Another thing to do is to use Spy++ to monitor all the processes in the
Dolphin window and see if a regular timer is firing, something like that.

Regards

Blair

On Sat, 23 Feb 2002 10:37:28 -0000, "Blair McGlashan" <[hidden email]>
wrote:

>>You could start by telling us which Active-X control you are using :-)

It is called QFeed ContinuumXClient. QFeed is a stock market datafeed from
quote.com. I originally thought it useless to mention because no one else
could try it. But actually I could legally distribute it and the problem might
be reproducible without having a subscription.

The control is obviously event oriented, but nothing that would account for
the cpu usage. There is a connection object which when signed on, issues a
heartbeat event (1/sec). But it take very little CPU. The CPU increase I
mentioned happened at control create time which is way before any signon or
any other objects like stock controls are created.

As I said though, things point away from the control. I looked at the source
of it and its just a thin wrapper on a C++ type dll (wish I could just code
directly to that DLL in dolphin, is that at all feasible?). When I use QCharts
which also uses the this qfeed dll, there is no CPU problem even with several
stock charts displayed while the market is open.

Also,  at times when I tried reproducing the problem, the control opened with
no CPU increase.
>
>Another thing to do is to use Spy++ to monitor all the processes in the
>Dolphin window and see if a regular timer is firing, something like that.

Is that part of VC++ or is it publicly available? I checked ms site and also
cnet/davecentral for knockoff tools but no luck.

This is a biggie for me cuz even under optimal conditions the main problem in
my app is maxing out the CPU (number crunching stock quotes in real time).

Alan Reider wrote.

>  I think it might be related to ActiveX. The reason is at some point I
noticed
> that the CPU would jump from < 10% to 60%  (and stay there) when
> single-stepping over a call to IaXWinHostWindow>>createControlEx..

Possibly related.  I've noticed (D4 and D5 under W2k) that if I open the
Active-X ControlBrowser, and start a "Windows Media Player" control
(MediaPlayer.MediaPlayer.1) inside it, then my CPU goes up to around 25%-40%
and stays there.  This doesn't happen if I run the Windows media player on
its own.  It also doesn't happen for other Active-X controls that I've
tried.

    -- chris

On Sat, 23 Feb 2002 09:50:06 -0500, Alan Reider
<[hidden email]> wrote:

>As I said though, things point away from the control.

Now I have definitely narrowed it back to the opening of this control. In a
clean, freshly started image, if I just run

AXControlSite progId: 'ContinuumClientX.ContinuumClientCtrl.1'

and single step through it, when I step over

CreateControlEx:hWnd:pStream:ppUnk:riidAdvise:punkAdvise:bstrLicenseKey

the CPU shoots up from nothing to 80% and stays there until I close Dolphin.
This should be very easy to reproduce:

1) installing the control from:
        http://briefcase.yahoo.com/areider   pub\setupContinuumX.exe
2) wrapping the control with the wizard
3) AXControlSite progId: 'ContinuumClientX.ContinuumClientCtrl.1'

regards,
alan reider

Alan,

> I'm not sure but I believe I saw this on D4 as well. Something in the
Dolphn
> process is revving the CPU ..

Can't help much with the control problem but I was wondering if you actually
see a slowdown or sluggishness when using the machine. My systems always run
at 100% CPU as I have got a background distributed computing application
running 24/7. It doesn't cause any problems performance wise as it is at a
very low priority and yields to everything. I just wondered if your control
was doing something similar and it wasn't actually a problem?.

Just being nosy :)

Regards
    Ian

Hi Ian,

On Sat, 23 Feb 2002 21:12:44 -0000, "Ian Bartholomew" <[hidden email]>
wrote:
>Can't help much with the control problem but I was wondering if you actually
>see a slowdown or sluggishness when using the machine. My systems always run
>at 100% CPU as I have got a background distributed computing application
>running 24/7. It doesn't cause any problems performance wise as it is at a
>very low priority and yields to everything. I just wondered if your control
>was doing something similar and it wasn't actually a problem?.

I dont know what the activity is or at what priority it is running. I can't
say at this point that I have experienced it as a drain on other tasks. But
clearly, one could never release an app to users which, when they just opened
it, caused the cpu to go to 80%.

Traders (like myself, and my target audience) are very sensitive to how much
CPU any given trading app even *appears* to be taking. They'd take one look at
it and then remove it from their machine.

Anyway I am fairly certain at this point, that it is not the control itself
doing anything, based on my experience and others using this control in other
environments than Dolphin.

>Just being nosy :)

not at all :) see my other post for what this control is.

regards,
alan

Alan,

> >As I said though, things point away from the control.
>
> Now I have definitely narrowed it back to the opening of this control. In
a
> clean, freshly started image, if I just run
>
> AXControlSite progId: 'ContinuumClientX.ContinuumClientCtrl.1'
>
> and single step through it, when I step over
>
> CreateControlEx:hWnd:pStream:ppUnk:riidAdvise:punkAdvise:bstrLicenseKey
>
> the CPU shoots up from nothing to 80% and stays there until I close
Dolphin.
> This should be very easy to reproduce:
>
> 1) installing the control from:
> http://briefcase.yahoo.com/areider   pub\setupContinuumX.exe
> 2) wrapping the control with the wizard
> 3) AXControlSite progId: 'ContinuumClientX.ContinuumClientCtrl.1'

There are some strange problems involved on occasion when connecting to
Quote.com. Much of this is to do with the search for active servers. I'm not
sure whether this is anything to do with the ActiveX control but I have seen
situations where Metastock will sit in a loop consuming CPU trying to
connect to Quote.com when QCharts will connect just fine.

It turns out that the way to fix the Metastock problem was to copy the
ContinuumClient.ini file from the working QCharts setup into the place where
Metastock could find it. Apparently QCharts has a better searching algorithm
for servers compared with the connection mechanism that Metastock uses and
is able to write a new ordered list of servers to search into the INI file.
Perhaps Metastock uses the ActiveX control, I don't know.

In any case, I very much doubt that the problem is Dolphin related,
especially since it is obviously not looping in Dolphin code but, rather,
within the call to CreateControlEx(). My guess would be that, if the above
suggestion doesn't work, you'll need to contact Quote.com technical support
for some guidance here.

FWIW: AXControlSite progId: 'ContinuumClientX.ContinuumClientCtrl.1'

works fine on my machine. If I get the situation where Metastock won't
connect again then I'll also try the Dolphin connection to see if that fails
in a manner similar to what you've observed.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy,

I think I nailed it. Your post got me thinking in the right direction. How
could it start right after the callout to CreateControlEx? The process is
paused and there are no ax windows open yet to receive messages so theres no
way it could be in smalltalk code . And why dont you have the same problem?
And also the Metastock story.

It has to be that when continuum starts, it activates some bg worker threads
(for server search and who knows what else) and its just a buggy version of
their dll.

Sure enough I had half a dozen vintages of continuumclient.dll on my machine.
I got rid of all but one with with version 12 14 2001. (I think the one dated
5/2001 was the culprit). After rebooting, the problem appears to have gone
away. What a relief :)

regards,
alan



On Sun, 24 Feb 2002 00:13:15 -0000, "Andy Bower" <[hidden email]>