Ted Waldron III has 10 years of application and operating systems development for real-time super minicomputers with strong emphasis on CPU scheduling. He is the sole owner of the OS/2 2.0, 2.1 and SMP 2.11 schedulers. Ted is the author or coauthor of 5 US software patents and internationally published articles. He is also the president of ScheduPerformace, Inc. which markets the Priority Master II OS/2 applications.
Blast Back! Send a private message directly to Ted Waldron III with your thoughts:
Go to a Printer Friendly version of this page
Summary: Ted Waldron III, author of Priority Master II for OS/2, writes a guest article for us on how to use his program to tune and improve the performance of your PC, all with a few changes to the way your applications are prioritized.
This article is intended for OS/2 users and developers, managers, MIS directors, and anyone else using OS/2. This will cover the basic elements of multitasking and using the Priority Master II Version 2.4 program to tune your system. More detailed information on OS/2's scheduling policies and technical information is available at: White paper on Prioritization and in The Electronic Developer Magazine for OS/2 OS/2's Symmetrical Multiprocessing Demystified. The program itself is available on the OS/2 Supersite and a half priced Lite version (.EXE, 574K) is also available too.
Priority Master II, version 2.4 can be used to tune your system by solving classical problems in your computer's scheduling, resulting in superior performance and control of your system's resources and increasing overall user responsiveness for the applications that you prioritize. The user can assign and change the priority of applications based on the dynamic conditions inherent in a business environment. Using the program, you should be able to reduce your computing needs by at least 1/2 hour per day per employee.
User response time
The main point of prioritizing programs is to be able to run 2 or more programs at once and control the order in which programs will get access to the CPU. The program that is highest in priority will use all of the CPU time that it needs and relinquish control to the next higher program all the way down to the lowest priority program. When two programs are the same priority, they will be scheduled to run one after another in round-robin fashion. The main point of a priority preemptive design is to allow the system to react to user requests based on the actual priority of the programs running. The program that gets all of the CPU time that it needs will have the fastest user response time. When a program gets only a fraction of the CPU time that it needs, the response time gets longer.
So, in effect, the more programs that are running, the slower the average response time becomes using OS/2's regular scheduling policy. Currently, the foreground program generally gets the highest priority and everything in the background shares the CPU equally. Background programs, although lower in priority, can receive a system applied boost for I/O and starvation (based on MAXWAIT in CONFIG.SYS) that are higher than the foreground program. Users know this and will typically run fewer programs to maintain acceptable response times for the foreground application.
Priority Master overcomes these potential problems so the user can get the best possible response time and greater system performance, running many more programs simultaneously than they could do before.
Prioritization on OS/2
OS/2 Warp out of the box supports user-level prioritization for DOS and Windows applications via the Settings or Properties. These are given 32 levels to execute in the Regular Class, which is the default. OS/2 programs in the background will suffer severe performance penalties when there are DOS or Windows programs executing in the foreground or background, even at the default priority. Even one level above default for a DOS or Window program and background OS/2 programs will get virtually no CPU time. What is really missing is the capability to prioritize OS/2 programs, and that is where Priority Master comes in to fill that void.
OS/2 supports 128 priority levels which are divided into 4 classes, each having 32 sub-levels. From highest to lowest the classes are: Time Critical, Server, Regular and Idle. However, over 95% of the time, less than 10 of the 128 levels are actually used. All OS/2 programs can be divided into two categories: those that set their own priority internally and those that do not set their own priority. All OS/2 programs that do not set their own priority internally can be prioritized by the user with the help of Priority Master. Programs that do set their own priority may or may not be prioritized. This depends on their internal settings.
The benefits of prioritization
Prioritization allows to you work smarter instead of harder or longer. When assigning a priority to a program, you actually control the response time that you want to wait. A system running with a mix of priorities is far more efficient than without. Part of the reason is that if a low priority program is too low to get any CPU time, it also does not have the opportunity to consume your systems resources. Therefore, more system resources are available to higher priority programs. Prioritization manages memory and CPU time at the maximum efficiency possible, regardless of what CPU is being used or how much memory is available.
For example, consider 4 programs that need 8MB of memory each. If they are all at the same priority level, it can require 32MB (4 x 8) at any one time. If you assign them a unique priority level each, something completely different happens. The one with the highest priority will get the CPU and hold onto it for all of the time that it needs. When it reads from the disk, keyboard, or simply lets go of the CPU, the next higher program gets the CPU. When the original program needs the CPU again, it simply takes control from whatever program was executing at the time. Over time, the highest priority program would complete and some the lower priority programs would get a tiny fraction of the CPU time. As the second one was completing, most of the CPU time would go to the third program and so forth. The net effect is that you could complete the 4 jobs with less than 16MB and all four would complete much faster than their non-prioritized counterparts. The bottom line is that you can significantly overload your system and still maintain excellent response time when you use a program like Priority Master.
Dynamically modifying the priority greatly extends the usefulness of prioritization along with the visual representation of the priority on the main window's title bar. Blindly changing the priority of a program can be dangerous in that a system crash could occur or the program may produce incorrect results. Priority Master solves this problem by performing a detailed analysis of the program and reporting a passed or failed status. A failed status does not necessarily mean that changing the priority of the program will result in any kind of a problem, but it does mean that the potential for a problem exists.
Some of the more obvious uses of prioritization include:
Substantial performance benefits can be achieved immediately by using PRIORITY=ABSOLUTE in the CONFIG.SYS file for any file, application or web server. Enormous benefits are also derived for Symmetrical Multiprocessors (SMP) even with just two CPUs. Better still, the effect should be geometric for additional processors. Why? This is because the standard OS/2 defaults to dynamic priority variation which gives a boost for every I/O operation. This generally results in a preemption when the I/O completes, due to the increase in priority for the returning thread. With just a few dozen users or applications, the CPU is thrashing between the programs. The effect compounds with hundreds of users and at some point, only the programs that are doing I/O are running. New users or new requests cannot be honored because the starting priority is far less than the boosted priority of the already running programs. Hence, saturation at I/O priority levels occurs. If the boosts are removed via the PRIORITY=ABSOLUTE in the CONFIG.SYS then far more users and applications can be run simultaneously.
The problem now is that server maintenance is next to impossible at the server. Without the priority boost for the foreground application, you have to wait for a very long time before an application could even be started on a busy system. Priority Master directly addresses this situation with the Set Foreground Program Priority option. This replaces OS/2's complex priority boost matrix with a simple foreground priority boost. Just start any OS/2 program using the default priority of Regular level zero and set the Foreground priority to level 1 or higher. When the program is in the foreground, it will automatically be boosted to the level that you set and return to default priority when in the background. This has a tiny fraction of the overhead compared to that of the boost applied in the default system. You may also run programs at very low priority so as not to interfere with the normal server activity. A ballpark performance figure would be about a 50% improvement for a single loaded processor.
On an SMP, the sky is the limit. If you have any server on OS/2, then add the PRIORITY=ABSOLUTE to your CONFIG.SYS, reboot, and run any benchmarks that you have. The more loaded the system is, the more the increase in performance will be achieved. If you need to do any work at the server, use Priority Master to get the response time that you want.
Using Priority Master II, 2.4
Before you start prioritizing any programs, there are a few general items that need to be considered. First is the information and warning messages. Every reasonable effort has been made to prevent a novice user from shooting themselves in the proverbial foot. Prioritizing programs is enormously complex and that is why IBM and Microsoft do not even tread on those waters. The information and warning messages are made very simple and always help to clarify or inform you before the program does anything that you do not want it to do. These should be turned on for the first week or so of use and can be turned off globally or at any of the dialogs.
The Auto Close Launched Programs on Exit is one useful feature that behaves a little like OS/2's "Work area" folders: When set, any programs started with Priority Master will automatically close when you exit Priority Master. This can be a real time saver when starting several programs and then closing them all at once at shutdown time. This isn't so good if you have warnings switched off and you accidentally find programs closing that you didn't want to close. As an exercise, use the Generate Multiple Sessions option in Priority Master and start about 20 OS/2 Windows. Close Priority Master and all 20 OS/2 Windows will close in about 3 seconds. If either the information or warning messages are on and you attempt to close the Priority Master program, you will have a chance to cancel and view the programs that would be automatically closed.
The Auto Recovery Window is your parachute when you set programs too high in priority to allow the system to run normally. You should leave this on all of the time. Several users have noted that it keeps popping up a recovery window every 60 seconds, which is the default. You can simply turn this option off. However, it is better to use the Active Program Snapshot (F4) a few times to find whichever program is hogging the CPU. If there are any controls provided by the program, use them to decrease its priority. In some rare cases (ie. calculating the value of pi to the last digit) this is OK. In general, avoid programs that consume all of the processor bandwidth. These are referred to as "compute bound" programs. When a compute bound program is running, lower priority programs will get very little or no CPU time. The net effect is that you loose all of the lower levels to do any unimportant work.
Setting the priority
Setting the priority of an OS/2 Window or Full screen is a relatively straight-foreword process. You just select the Prioritized OS/2 Window/Full Screen option and select a priority class and level. Note that any program that you start (even PM programs) will start with the original session's priority.
To store the settings for prioritized programs, use "Find Programs and Prioritize" to enter programs and their parameters into the program list. This is simply a standard open file dialog and another dialog for entering the parameters and working environment. A detailed description of how to enter the programs is at http://www.prioritymaster.com/tour.html which includes the graphic panels. It only takes about 10 to 20 seconds to enter a program.
Priority Master can simultaneously launch several frequently used programs faster than they can be using the desktop due to overlapping of the processing, which makes it probably one of the most used features. Note that there is a an option for Popup on Startup that can be set so that the list of prioritized programs dialog box is presented when starting the program. Also the priority, parameters and working environment can be edited at any time.
Command (.CMD) files can also be prioritized. Simply use the "Find Program and Prioritize" option and select the boot drive letter and the system directory, then select CMD.EXE and enter the name of the .CMD file in the optional parameters dialog.
You do not need to prioritize every program that you use. Just two or three prioritized programs can produce significant time savings. Programs that are launched by Priority Master can be controlled by dynamically changing their priority quickly and easily. The priority of the launched programs will also appear in the main window title bar and/or the CTRL+ESC Task List.
Examples of Priority Master at work
Priority Master can be used to make the background program higher in priority than the foreground. Retrieving files from a network is a good example.
If a large transfer is needed, start a prioritized OS/2 Window and set the priority to time critical. Use something like xcopy or any program to do the transfer. Now do anything else that you would like to at the foreground and time how long it takes to transfer the files. Now try listing a large file ("TYPE FILE.TXT" at the command line) in a Regular level 0 (default) window. Try the same test and do not prioritize the network transfer. There should be a big difference in the time that it takes to transfer the file(s) in the background.
Now suppose that you want to CHKDSK all your hard drives at once. Use the Generate Multiple Session and start 4 prioritized windows starting at Idle class level zero with auto-increment on. This generates an Idle 0, Idle 1, Idle 2 and Idle 3 OS/2 windows at Idle priority. Set the Idle 3 to be the boot drive and the other sessions for the other drive letters. Type "CHKDSK" in each of the Idle class windows and do not hit Enter yet. Now start your timer and hit Enter for all for windows. Keep a record of when each one completed. If CHKDSK reports a lot of errors, correct them and repeat the test. Now try the same test using 4 standard (un prioritized) OS/2 windows. You will see a big difference in the time that it takes to complete the tests. This is because the Idle class does not get any system applied boosts for doing I/O and the unique priority level combine to give the best performance. This is also part of the reason that a server using PRIORITY=ABSOLUTE gets better performance.
Understanding how priority in the background effects performance can be easily visually demonstrated. Start two prioritized OS/2 windows using the "Generate Multiple Sessions" option, beginning with Regular level 0. In each window enter "type readme" (in a directory with a "readme" file) and do not hit Enter. Now that both are ready to run, hit Enter on both sessions as fast as you can and set the focus to the desktop so that both sessions are unhighlighted (not in the foreground). Note that the session that is Regular 1 is getting most of the CPU time and the Regular level 0 (system default) is getting very little in comparison. In fact, it is only getting the starvation boost based on the MAXWAIT in CONFIG.SYS. If MAXWAIT is set to 1, the Regular level 0 will get 1/30th of the CPU time per second. If it is set to 3, then the Regular level 0 will get 3/30th or 1/10th of the CPU per second.
The Priority Scanning Logic
Most of your compute bound programs should go in the Idle class with the exception of PM programs. PM programs cannot be scheduled in the Idle class because the PM message queue needs the priority boost. To demonstrate the priority scanning logic, start a prioritized OS/2 window at Idle level 25. In the window, again enter "type readme" (or the name of some other large text file) and do not yet hit Enter. Now start another prioritized OS/2 window at level 0, typing in the same command but not yet hitting Enter. Go back to the Idle 25 window and hit Enter, then to the Idle level 0 and hit Enter too. The message "Current Idle Level is too low to execute. Would you like to engage the automatic level seek logic? The scan will be reflected in the Main Window Title Bar." will appear. Select Yes and the scan will start an OS/2 window at Idle Class Level 26.
This demonstrates that the new program can execute without delay, plus any CPU time that it does not need will be given to the Idle Level 25 compute bound program. On systems using the default value for the PRIORITY statement in the CONFIG.SYS (which it defaults to, so the statement and value is missing), the priority scanning logic will always allow programs to be started in the Regular and Server classes due the very high priority system applied boost at the time the program starts.
The Show Active Program Snapshot and Show All Priorities
The priorities that are displayed represent the base program priority in default systems (dynamic priority variation). PM programs inherently have a very high priority which is not reflected in the either of these reports. When a REG 0 is displayed, it is really much higher than Server level 31 but less than Time Critical. The priority actually floats based on whatever system applied boost is in effect at any given moment in time. On systems using PRIORITY=ABSOLUTE this not true - what you see is what you get. You need to keep this in mind when assigning priorities to command files, windows, full screens, and VIO programs.
The Check CONFIG.SYS Utility
This has two modes: client and server. In the client case, it is important to distinguish between systems running all OS/2 programs and systems running a mix of OS/2 programs and DOS or Windows 3.1 concurrently. The default is dynamic timeslicing which gives the best performance in most situations. However, it fails miserably when there are DOS or Windows programs at the same priority as OS/2 programs in the background. This is because there is the potential for DOS or Windows 3.1 CPU hogs to be "gluttons" in the extreme. Using "TIMESLICE=32,32" in the CONFIG.SYS will bail you out of the lost CPU time due to the extended timeslice of these programs. However, a better solution is make sure that all OS/2 programs are at least one level higher than any of the DOS or Windows 3.1 programs you run, also adjusting their Setting or Properties so that that they are not compute bound. Simply run the program and use the Static Idle Test in the Utilities menu of Priority Master, then make adjustments in the DOS/Windows program's properties until the test reports idle cycles are present.
This will make your entire system run better and keep the power of the dynamic timeslicing working for you instead of against you.
Priority Inversion and PRIORITY=ABSOLUTE
Although it is recommended that this only be used for a server, it can also be used for a client. It gives the environment very tight control over the amount of CPU and resources that each program receives. This would also imply that you would have to actually set each program's priorities yourself, otherwise everything would default to Regular level zero and you would end up with nearly a traditional time-distribution system like of the mainframes of the past. Yet it would also flush out very badly written programs in terms of their internal priority assignments. This is very rare, but can happen. When a multithreaded program has two or more threads of different priorities, a priority inversion is possible. This occurs when a thread of low priority owns a process wide resource (such as a semaphore) and the higher priority thread spins waiting on the low priority thread to run and release the resource. In standard OS/2 systems, the scheduler will eventually give the low priority thread a starvation boost based on MAXWAIT in the CONFIG.SYS. So a value of 3 (default) would perform a hard spin for the higher priority thread, the boost to the low priority thread would be invoked after the 3 second limit and it would run and release the resource.
If the MAXWAIT value was 10 (10 seconds), then 10 seconds would be required to resolve the priority inversion. On a system with PRIORITY=ABSOLUTE, the conflict would never be resolved and the program would simply hang. This is CPU independent. An i486 33MHz would loose 3 seconds of CPU time, while a 450MHz Pentuim II would also loose 3 seconds. So, if you use the PRIORITY=ABSOLUTE option and the program hangs, you just a found a CPU killer! You can verify this easily using the Active Program Snapshot or just change the value of MAXWAIT in the standard system and see if the delay in the program matches the number of seconds that you set for the MAXWAIT variable. The question is that if a "bad" program is running on your system, don't you want to know about it? On the other hand, don't try this on a production system that cannot have any possibility for a hang.
Many large corporations have policies regarding games or just surfing the web during normal business hours. However, there are some cases in which it is known that an activity will take several minutes or even a 1/2 hour to complete. For example, copying a large number of files from a network or doing a long database scan. In that event, if the "work" activity was set to time critical and the "play" activity was set to regular priority, you could be certain that work was proceeding at top speed. That may make the "play" activity have slower responses, but you would be using otherwise wasted CPU time if you were doing nothing else. If a manager witnessed you viewing a game or surfing the web, it would be a simple matter to do a CTRL+ESC and see that the priority of the real work was higher in priority that than the "play" activity.
Some people will be better at setting the priority to properly load balance their systems than others. It would be easy to see what priority the other people are running by just looking at the priority in the main window titles on their desktop or doing a CTRL+ESC and looking at the Task List. For various reasons, some people will not prioritize any programs even if they have the capability. After all, if you were a contractor being paid by the hour, would you like to be forced to run multiple programs and keep track of them when you can be paid the same amount for running just one program? Conversely, from a managerial point of view, wouldn't you like to see your employees making efficient use of their machines and time? After all, many employees have things like stock quotes updated constantly, news, weather, even listening to Real Audio on the net while they are "working". Do they impact performance? You bet. Isn't it about time that we all get our "priorities" straight?
It has been remarked that "Nobody really does multitasking", meaning that no matter how many programs are actually loaded, they are only working on the one in the foreground and any background programs are actually idle. Just looking at all of the performance problems that you can run into when running several programs simultaneously, it is little wonder. However, with the control and performance provided in Priority Master, the floodgates to true heavy-duty multitasking are now open for business.
|Copyright © 1998 - Falcon Networking||ISSN 1203-5696||October 16, 1998|