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 >and >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 > > [EMAIL PROTECTED] > > 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: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
