On 05:42 PM 24/07/2002 -0700, Dennis Saputelli said:
>i was going to argue with you until ....
>i went and tried it!
>jeez even place line (not track) with no connectivity or anything
>much on the board chews up 100% CPU continually !!
>you don't even have to be drawing or holding the mouse button
>it doesn't seem to effect typing this though, i left it in place line
>switched to this email and it's still chugging away at full 100% usage
>i then tried a few simple tasks and sluggishness was hardly noticeable
>including opening a jpg in PSP and editing it
>so i guess i am not sure what 100% usage really means
>Dennis Saputelli

Since threads can have different priorities it is perfectly possible for a 
system to be showing 100% CPU utilisation but no apparent slow down for 
other applications.  If the thread that is running all the time has a lower 
priority than the user interface thread and normal application threads then 
the background thread will be preempted by higher priority stuff (like PSP, 
or typing an email).

Those that remember back to P99 will recall the floating license server 
worked in this way (soaking up all available CPU idle time) but had little 
effect on system responsiveness.

My guess is that a similar thing is happening - that is the place-track 
command has to interface to a number of robots (as the Protel SDK calls 
them), maybe these run as low priority threads.  Using low priority threads 
is a common enough programming practice fro idle time processing, and will 
often cause the CPU usage to run higher than expected without any apparent 
side-effects. I s'pose it is usually better to think carefully about adding 
threads willy-nilly to a program as excessive numbers of threads do slow 
down the task swapping kernel a little - though this is normally only a 
problem on seriously big scaled-up server type systems.

I wouldn't worry too much about an application that causes the CPU usage to 
go to 100% while doing nothing, unless the programmers have been so rude as 
to do this with a normal or higher-than-normal priority thread.

I just did some checking - the thread that is taking up all the processing 
time is thread 0 of the P99SE instance.  Normally this would be the main UI 
thread.  So that sort of goes against the stuff I was writing above.  What 
may be happening is that when the user has a command under way Protel is in 
a tight loop (so using 100% CPU) but the thread priority drops a little 
(this can be seen by monitoring with the Performance mmc plugin in Win2k) 
so reducing the impact on the system.  there are also methids by which the 
application can release itself from a tight loop to allow the application 
message queue to be processed, so allowing screen redraws etc.  Why would 
Protel go into a tight loop when a command is active?  Maybe to interface 
to the robots, or to allow the crosshair cursor to be managed correctly 
(recall that Protel adds its own grid-locked cursor on top of the system 
cursor) or maybe to implement the auto-pan or ...???

If it doesn't affect system responsiveness it is probably not something to 
worry about greatly.

Ian Wilson

> > My favorite example of Protel poor multitasking design:
> > Open your task manager & go to the performance tab.
> > Open a Protel PCB & press P-T. (Place track.)
> > Watch your CPU utilization & laugh.
> >
> > ____________
> > Brian Guralnick
> > Voice (514) 624-4003
> > Fax (514) 624-3631
> >
>* Tracking #: 0F6CE7DFD220B84CB875D24231133B12907E9A45
>www.integratedcontrolsinc.com            Integrated Controls, Inc.
>    tel: 415-647-0480                        2851 21st Street
>       fax: 415-647-3003                        San Francisco, CA 94110

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
* Contact the list manager:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to