CPU Consumption?

I am getting reports from a user with a Dell 2.53GHz Pentium 4 with 512 MB
Ram. The operating system is MS Windows 2000 Release 5.00.2195 Service Pack
3 that our program is using 100% of the CPU time even after they change
focus to another application.  In fact they are seeing a delay of several
minutes in file open dialogs in MS Word.

The problem is that I can not reproduce this delay on my Windows XP machine,
and have never experience anything like this in prior versions of Dolphin on
2000 or NT.  If anything Dolphin used to give up too much CPU time.

Has anyone else experienced anything like this?  Any thoughts on how to
debug this?  My first thought is to put something like the process monitor
in the stand alone and see what the processes think they are doing.  However
I suppose the act of inspecting them is likely to effect the results.

Chris

Chris,

> I am getting reports from a user with a Dell 2.53GHz Pentium 4 with 512 MB
> Ram. The operating system is MS Windows 2000 Release 5.00.2195 Service
Pack
> 3 that our program is using 100% of the CPU time even after they change
> focus to another application.  In fact they are seeing a delay of several
> minutes in file open dialogs in MS Word.

Finally, somebody is stealing clock cycles from MS :)  Is it a
multi-processor machine?


> The problem is that I can not reproduce this delay on my Windows XP
machine,
> and have never experience anything like this in prior versions of Dolphin
on
> 2000 or NT.  If anything Dolphin used to give up too much CPU time.

The D5(??) fix for that seems to work, as I've not had problems running
with/against Access, which was the worst offender I saw.


> Has anyone else experienced anything like this?

Not really, though I do have an open problem with MySQL.  That's starting to
look like a query that goes bad causing the MySQL service to hog the CPU,
with my app being frozen until the service is stopped.  Interestingly,
stopping the service causes the Dolphin app to handle a database error and
otherwise behave quite normally.  Bottom line, I do not think the problem is
in Dolphin, but I cannot yet prove that.


> Any thoughts on how to
> debug this?  My first thought is to put something like the process monitor
> in the stand alone and see what the processes think they are doing.

In runtime systems, I have "always" mapped control-break to something that
dumps a call stack for every Dolphin process, which is very helpful for
finding deadlocks.  If an app appears to have frozen, I will hit
control-break several times to see if it logs anything.  I also have menu
commands that do the same thing, and use them if I suspect a problem but the
GUI is responsive.


> However
> I suppose the act of inspecting them is likely to effect the results.

Please send my regards to Dr. Heisenberg.  If your problem is a simple
deadlock (which I doubt), then it's probably going to be fine - the thread
dumps would show, for example, that you have a wait wrapped in an
overly-generous critical section and since the blocked threads are going
nowhere, the picture would be quite stable.  If you are blocking the main
thread, then you might get some fairly interesting stacks, but they could
still be revealing - I'll gladly defer to Blair on what can happen.

I suspect that the real problem is with something that you called.  If you
are overlapping calls, you might try them as blocking calls; not all thread
affinities are documented.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

On Mon, 16 Jun 2003 18:29:25 -0400,
Christopher J. Demers <[hidden email]> wrote:
> I am getting reports from a user with a Dell 2.53GHz Pentium 4 with 512 MB
> Ram. The operating system is MS Windows 2000 Release 5.00.2195 Service Pack
> 3 that our program is using 100% of the CPU time even after they change
> focus to another application.  In fact they are seeing a delay of several
> minutes in file open dialogs in MS Word.

FWIW, one of my customers with *no* Dolphin app but Win2k SP3 and
lots of CAD software has a similar problem: Word 2K takes about
half a minute to start up, while Excel 2k pops up almost immediately
on his box.

Before applying SP3 this was definitely not the case.

s.

Chris

You wrote in message news:bclgc3$k70cm$[hidden email]...
> I am getting reports from a user with a Dell 2.53GHz Pentium 4 with 512 MB
> Ram. The operating system is MS Windows 2000 Release 5.00.2195 Service
Pack
> 3 that our program is using 100% of the CPU time even after they change
> focus to another application.  In fact they are seeing a delay of several
> minutes in file open dialogs in MS Word.
>
> The problem is that I can not reproduce this delay on my Windows XP
machine,
> and have never experience anything like this in prior versions of Dolphin
on
> 2000 or NT.  If anything Dolphin used to give up too much CPU time.

The issue of Dolphin yielding too readily to CPU hogs (#355 if you want to
refer to the release notes) was fixed in the original D5 release - it was
caused by too frequent calls to SleepEx().

A couple of related issues were:
1) #969: "Dolphin burns 100% CPU when main UI process blocked on Semaphore"
2) #1272: "Idle time UI validation stalls intermittently on Windows 98"
3) #1249: "Noticeable delay before message boxes appear"

#969 was fixed in Dolphin 5.1, causing #1249 and #1272, which in  turn was
patched in 5.1.1. As far as we know #1272 only showed up on Win9x,
apparently being due to a bug in a system API on that platform. #1249 was a
manifestation of repeated UI validations occurring before the system went
idle, and would cause CPU hogging behaviour for "short" periods when the
system should have quiesced. Do you have PL1 installed?

>
> Has anyone else experienced anything like this?  Any thoughts on how to
> debug this?  My first thought is to put something like the process monitor
> in the stand alone and see what the processes think they are doing.
However
> I suppose the act of inspecting them is likely to effect the results.

You could certainly do something like that, but as you say there is always
the possibility that what you observe is not what you would observe should
you not have been observing...

I would suggest a couple of approaches:
1) Try using a regular windows timer to dump the stacks of all processes
that are ready to run each time it fires.
2) Do the same with a high priority process.
3) Bill's idea of hooking a key press to initiate a VM dump, or some other
dump of all process stacks.

(1) would have similar effects on the system to the observation that the
process monitor performs. If the issue is related to the message
queue/failure of the UI processing to go idle, then this will probably
render any results uninteresting. (2) would perhaps be more useful where
that is the case. When the UI is responsive, (3) is perhaps best achieved by
registering a hot key (like a global accelerator) with the OS, using the
RegisterHotKey() API. You can also hook the Ctrl+Break interrupt by
overriding SessionManager>>onUserBreak.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:bcmkg9$l5fgt$[hidden email]...
> Chris
>
> You wrote in message news:bclgc3$k70cm$[hidden email]...
> > I am getting reports from a user with a Dell 2.53GHz Pentium 4 with 512
MB
> > Ram. The operating system is MS Windows 2000 Release 5.00.2195 Service
> Pack
> > 3 that our program is using 100% of the CPU time even after they change
> > focus to another application.  In fact they are seeing a delay of
several
> > minutes in file open dialogs in MS Word.
...
> system should have quiesced. Do you have PL1 installed?

Yes, PL1 is installed in the deployed EXE.
...
> registering a hot key (like a global accelerator) with the OS, using the
> RegisterHotKey() API. You can also hook the Ctrl+Break interrupt by
> overriding SessionManager>>onUserBreak.
...

Something more than just overriding onUserBreak must be required to hook
into Ctrl+Break.  I tried that, but my code never got called.  Perhaps Bill
can point me to what he does.  I ended up just adding an additional
accelerator to my main window to dump the processes.  It sounds like the
problem is easily reproducible for my user, all he has to do is run my
program, minimize it and try to open a document in Word.  I don't see
anything unusual when I dump the processes to a log.

I had the user try lowering the program task priority.  Even at
"BellowNormal" he saw a massive slowdown in my program.  File loading took 1
second at "Normal", and 30 seconds at "BellowNormal".  Even just scrolling
through items in a list was much slower for him.  I find this interesting
because when I lower the priority on my system even to "Low" I don't really
see much of a speed difference.

It turns out that the only thing that he notices is slow when running my
program is the Word file open dialog. Without my program running the Word
file open dialog opens instantaneously, but with my program running it takes
30 seconds before he can see the files listed.

I am wondering if there may be some kind of network interaction going on.  I
think I will experiment with sending him something like the notepad example
and see if that has the same problem.  If it turns out to be a generic
Dolphin issue on his system then I will look into adding the "excessive
system yielding" back into the image (as an option).  I will keep the group
posted incase this has any use for others.

Chris

Chris

You wrote in message news:bctb1e$mr93m$[hidden email]...
> ...
>
> Something more than just overriding onUserBreak must be required to hook
> into Ctrl+Break.  I tried that, but my code never got called.  ...

No, that is all that is required, however Ctrl+Break won't actually do
anything unless there is a "looping" process. You can demonstrate this in
the development environment by bashing away at Ctrl+Break when the system
has just been started and is in a normal state.

Now run a CPU hogging process such as this:
[[(1 to: 10000000) asSortedCollection]repeat] forkAt: Processor
userBackgroundPriority

And try again. It should interrupt immediately when you press Ctrl+Break.
The top of the stack will look like this:

08:34:46, 20 June 2003: 'User Interrupt'
Signal>>signal
DevelopmentSessionManager(SessionManager)>>onUserBreak
ProcessorScheduler>>userBreak:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
SortedCollection class>>value:value:
SortedCollection>>quicksortFrom:to:
...

So you can see that the hog has been interrupted, and the interrupt is
forwarded on to the #onUserBreak method for handling.

Now if it is that case the Ctrl+Break does nothing on your user's system,
that suggests there isn't actually looping process.

Is it possible that your user is interpreting the symptoms of running the
Dolphin app making the Word file-open dialog slow to open as suggesting that
app is hogging the CPU when this isn't actually what is occurring? It's
probably worth asking him to report what he sees in the task manager, and
whether this confirms that the dolphin app is actually consuming all the
processor time. Also if it is apparently clocking 100% CPU, does it do this
all the time, only when minimized, or only when the Word dialog is opening?
Does it quiesce properly at any point?

> ...
> I had the user try lowering the program task priority.  Even at
> "BellowNormal" he saw a massive slowdown in my program.  File loading took
1
> second at "Normal", and 30 seconds at "BellowNormal".  Even just scrolling
> through items in a list was much slower for him.  I find this interesting
> because when I lower the priority on my system even to "Low" I don't
really
> see much of a speed difference.

Generally speaking you will see no effect unless there is another CPU
hogging process running at a higher priority. E.g. if you run a program like
"CPU Burn-in", and then lower your Dolphin app priority you will definitely
see it start to become very slow to repaint windows etc.

>
> It turns out that the only thing that he notices is slow when running my
> program is the Word file open dialog. Without my program running the Word
> file open dialog opens instantaneously, but with my program running it
takes
> 30 seconds before he can see the files listed.
>
> I am wondering if there may be some kind of network interaction going on.
I
> think I will experiment with sending him something like the notepad
example
> and see if that has the same problem.  If it turns out to be a generic
> Dolphin issue on his system then I will look into adding the "excessive
> system yielding" back into the image (as an option).  I will keep the
group
> posted incase this has any use for others.

Is it just the word file open dialog, or is it any file open dialog? I
remember a system I had at one point that was very slow to open that dialog
and it turned out to be due to a registry mess. A remote DCOM component was
registered that was on a network machine that was not present, and it seems
some kind of timeout had to occur every time before the dialog would open.

My gut feeling is that this isn't due to Dolphin consuming all the CPU all
the time (as the user originally reported), which could be confirmed one way
or the other by using the task manager, but is a configuration issue. If it
isn't due to a runaway Dolphin Process, then yielding in the image will
theoretically make no difference since it should actually have quiesced.

Thinks: Wouldn't it be a great feature of VMWare if it could take a ghosted
image of a machine and run it up for reproducing user support issues. Does
anybody know if it (or one of its competitors) can do that?

Regards

Blair

Blair McGlashan wrote:

> Thinks: Wouldn't it be a great feature of VMWare if it could take a
> ghosted image of a machine and run it up for reproducing user support
> issues. Does anybody know if it (or one of its competitors) can do
> that?

VMWare can't -- unless the original machine was also a VMWare image ;-)

    -- chris