Hello,
I have a unique problem under WINCE 5.0

I have a network application that seems to be hogging the CPU - It takes up
about 60-70% of the processor. This was unacceptable so I started looking
into what could be causing the problem. During this debugging process I
found something a little confusing ...

If I connect the Remote Call Profiler (simply connect, not even launching an
app or collecting data - i.e. just having ConPMon.exe running) my App's
efficiency all of a sudden drops to an expected value of 10-15% utilization.
My first thought was that the Remote Performance Monitor was just reporting
the utilization wrong so I ran a TOP like program and it verified this
behaviour. I still didn't like it so I hooked a scope up to my board and
used the idle routine and a led toggle and sure enough my scope shows the
same results.

So, I'm left with ConPMon.exe kicking my system into a "good" state. I can
disconnect the profiler, restart the app and everything is fine. The system
stays in a â??goodâ?? state. This happens if I connect via activesync or a tcp
manual cemgr. No other remote tool does this (put system into a "good"
state). Moreover, no other tool will remove the system from a "good" state
except for the Remote Kernel Tracker. If I try to use the Remote Kernel
Tracker all bets are off - the system goes back into a "bad" state and the
app runs at 60-70% CPU utilization.

Between these two system states the registry is the same. I've tried
switching thread priorities and quantum times of my app. With an OS debug
build the App runs at around 25% but comparing a retail build to a debug
build is a little trickier. I canâ??t seem to find out what constitutes a
â??goodâ?? state.

I'm leaning toward a socket select call or overall TCP/UDP state causing my
problem. The app is pretty simple and only single threaded. ConPMon.exe and
my App share the following module linkages:
wspm, ssllsp, ws2 (and of course coredll) - all IP "stuff".

If anyone is familiar with what might be going on while loading ConPMon.exe
and/or the remote kernel tracker and might have some ideas as to what their
threads might be changing I would greatly appreciate it.

Thanks in advance for you thoughts and advice,
Chris


--

Chris Kavanagh

Software Developer
LibreStream Technologies Inc.
www.LibreStream.com
Unit 200 - 55 Rothwell Rd.
Winnipeg, Manitoba
Canada R3P 2M5

RE: CPU Utilization Changing with Remote Tools by sloh

sloh
Thu Jun 23 14:34:04 CDT 2005

Wow, that is a weird one!

Perhaps you could try running the Monte Carlo profiler? There is some
chance that it won't disturb your system to the point of making the trouble
go away. It doesn't load any DLLs or anything.

Sue
sloh@microsoft.com (remove "online" from reply-to address)

Now writing to a different blog!
http://blogs.msdn.com/ce_base/

_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________


RE: CPU Utilization Changing with Remote Tools by Kav

Kav
Fri Jun 24 17:06:02 CDT 2005

Hello,
Thanks for the suggestion. I did play with the profiler from the CE Target
Control windows. I also tried turning off the memory tracking feature which
made everything nice :)

I guess the call profiler turns tracking off for optimization reasons?

Thanks for the suggestion,
Chris

--

Chris Kavanagh

Software Developer
LibreStream Technologies Inc.
www.LibreStream.com
Unit 200 - 55 Rothwell Rd.
Winnipeg, Manitoba
Canada R3P 2M5




""Susan Loh [MS]"" wrote:

> Wow, that is a weird one!
>
> Perhaps you could try running the Monte Carlo profiler? There is some
> chance that it won't disturb your system to the point of making the trouble
> go away. It doesn't load any DLLs or anything.
>
> Sue
> sloh@microsoft.com (remove "online" from reply-to address)
>
> Now writing to a different blog!
> http://blogs.msdn.com/ce_base/
>
> _____________________________________________________________
> This posting is provided "AS IS" with no warranties, and confers no rights.
> _____________________________________________________________
>
>