Modifying DOS Application Keyboard Polling Detection

Standard DOS applications will use nearly 100 percent of the system CPU because they constantly look for keyboard input whether the application is active (checking for keyboard input to be more responsive) or idle. Obviously, no application should be allowed to monopolize the CPU. In a Terminal Server environment keyboard polling can make a DOS application sluggish for a single user or can seriously limit the number of simultaneous users.

There are two ways to modify an applications keyboard polling. The first is to modify the applications properties, and the second is to use the DOS utility DOSKBD.

Determining that a Problem Exists
Application performance problems will be obvious to the user, but to get a more precise picture of application resource usage, use Performance Monitor. If you suspect a DOS application is monopolizing the CPU, Performance Monitor can tell you precisely how much CPU time the application is using. To avoid false readings, however, make sure that your Terminal Server is running as few system processes as possible. Performance Monitor should be the only running application other than a single client connection from which to run the DOS application.

In Performance Monitor, open a graph that displays total system CPU usage every second. Note the CPU usage before having the client run the DOS application. This will give you a baseline.

Now have the client run the DOS application and note the increased CPU usage.

Lowering CPU Usage Through Application Properties
Have the client close the DOS application. At the Terminal Server, run Explorer and highlight the applications executable file. Right-click on this file and select Properties from the popup list. On the Properties screen select Misc (miscellaneous). You will find a slider bar called Idle Sensitivity. This setting tells the system how much CPU time to allow the application to use while it is idle. Low sensitivity allows the application to use more CPU time. High sensitivity reduces allowable CPU time. In this case you want to increase sensitivity. Every application will be different, so determining the correct sensitivity level will necessitate some trial and error.

Note If you are familiar with Citrix Winframe, you may have used the PIF Editor to modify a DOS applicationss properties. Terminal Server uses the Windows NT 4.0 method, which is to right-click on the application name in Explorer and then open the applications properties. Whenever properties are changed, an application shortcut is created. You can place this shortcut on the users desktop, folder, or Start Menu. Launching the application from the shortcut will activate the properties you have selected. However, running the applications executable from a command line will not.

After you modify the application properties and exit the properties screen, a shortcut will be created with a default name identical to the application executable name. Use this shortcut to start the application. You can modify the shortcut name if you want to create multiple instances with different properties.

Have the client run this shortcut while you monitor Performance Monitor for decreased CPU utilization.

Note Modifying the application properties affects ONLY idle time. It does not decrease CPU utilization while the application is active (i.e. when the user is typing).

The DOSKBD Utility
The DOSKBD utility can decrease a DOS applications CPU usage from keyboard polling during both active and idle times. It is also much more complex than simply modifying the application properties.

DOSKBD works by monitoring how frequently the DOS application checks the keyboard buffer for input. If it checks too frequently during a specific interval (by default a single system timer tick), then the application is suspended or put to sleep for a short period of time.

DOSKBDs default values are in effect whenever a DOS application is started. The defaults, switches, and usage are detailed below. If you need to modify any of the default values, DOSKBD will need to be run with the new values from the same command prompt (or within the same DOS session) that you use to run the application. The easiest way to accomplish this is to create a batch file that runs DOSKBD with the appropriate settings and then runs the application. An alternative to using a batch file is to create a custom autoexec.nt file and associate it with the DOS applications shortcut properties.

By using batch files to run your DOS applications, you can set different values for DOSKBD as needed.

These are the default values for DOSKBD. These are the values in effect whenever a DOS window is opened.

• Number of milliseconds in a system timer tick is 10
• DetectionInterval = 1 tick(s) (10 msec)
• DetectProbationCount= 80
• InProbationCount= 35
• msAllowed= 0
• msSleep= 100
• BusymsAllowed= 60
• msProbationTrial= 2500
• msGoodProbationEnd= 2500

The poll detection algorithm is driven by how many keyboard polls happen within a polling detection interval. All units of time are rounded to a system timer tick. If too many keyboard polls occur within a detection interval, the application is put on probation and punished by being put to sleep for a predetermined amount of time. Once the application is on probation, the algorithm can be set up to punish the application after a fewer number of polls.

Activities such as updating the screen, doing file I/O, or getting mouse or keyboard activity cause the system to mark the application as busy. When the application is determined to be busy, it is awakened if it is being punished. In addition, the application is taken off probation.

If an application polls DetectProbationCount number of times within a given timer tick, the application is put into probation if BusymsAllowed number of milliseconds have elapsed since the last time the application was detected as busy. Once the application is put into probation for msAllowed milliseconds, it is punished for exceeding the allowed number of polls within a timer tick by being put to sleep for msSleep number of milliseconds.

While the application is on probation, the number of allowed polls is reduced to InProbationCount from DetectProbationCount. After exceeding the allowed number of polls, it is put to sleep as long as msAllowed milliseconds have elapsed since the application probation.

The application is taken off probation if msGoodProbationEnd milliseconds have elapsed since the application was last punished. In addition, every msProbationTrial milliseconds, the allowed number of polls in a timer tick is increased to DetectProbationCount. As long as the application is not punished, the allowed number of polls stays at the higher level. If the application exceeds that level, the allowed level of polls is reduced to InProbationCount.

DOSKBD Command Line Switches, Syntax, and Values
At a command prompt, type DOSKBD /? to display how to use DOSKBD. To display the current settings, type just DOSKBD. The number of milliseconds in a system timer tick is also displayed.

DOSKBD
DOSKBD /DEFAULTS [/Q]
DOSKBD [/DETECTPROBATIONCOUNT:nnn] [/INPROBATIONCOUNT:nnn] [/MSALLOWED:nnn] [/MSSLEEP:nnn] [/BUSYMSALLOWED:nnn] [/MSPROBATIONTRIAL:nnn] [/MSGOODPROBATIONEND:nnn] [/DETECTIONINTERVAL:nnn] [/STARTMONITOR [appname] | /STOPMONITOR] [/Q]
DOSKBD displays the current settings.
DOSKBD /DEFAULTS resets all tuning parameters to the system defaults.
Any DOSKBD command line ending with /Q will not display any information.
Note Valid range for all values (represented by nnn) is 0 to 32767.
/DETECTPROBATIONCOUNT:nnn
The number of peeks in the detection interval required to force the application into the probation state and to sleep the application.
/INPROBATIONCOUNT:nnn
The number of peeks in the detection interval required to sleep the application when the application is in probation. Should be <= DETECTPROBATIONCOUNT.
/MSALLOWED:nnn
The number of milliseconds the application is allowed to be in the probation state before the system starts sleeping the application.
/MSSLEEP:nnn
The number of milliseconds that the application is put to sleep.
/BUSYMSALLOWED:nnn
When the application is detected as 'busy', the application cannot be put into the probation state for this # of milliseconds.
/MSPROBATIONTRIAL:nnn
When the application is in probation, DETECTPROBATIONCOUNT is used instead of INPROBATIONCOUNT every MSPROBATIONTRIAL milliseconds.
/MSGOODPROBATIONEND:nnn
When the application is in probation it must avoid being put to sleep for this # of milliseconds in order to be removed from probation.
/DETECTIONINTERVAL:nnn
The length of time (in ticks) used to count up the number of polling events.
/STARTMONITOR [appname]
Start gathering polling statistics.
/STOPMONITOR
Stop gathering polling information and display statistics.

How to Use DOSKBD
The typical scenario is that a DOS application runs fine for a single user, but the system slows down when more users start using the application. In this scenario it is possible that the polling detection is not being aggressive enough to put the application into probation. Observe how much CPU the application is using while doing nothing and while doing common operations. Then exit the application and use DOSKBD to refine the polling parameters. Remember that DOSKBD settings only affect the DOS session in which they are set, so it may be best to modify your DOSKBD settings and run the DOS application within a batch file or through the use of a custom autoexec.nt file.

Changing parameters by about 30 percent per try is recommended.

To more aggressively take the CPU away from the application, first try lowering DetectProbationCount and InProbationCount.

If that does not help or does not help enough, try lowering BusymsAllowed 10 milliseconds per try. The default of msAllowed is already zero. Assuming that polling is being detected, the CPU should be significantly below 100 percent by now.

At this point it is important to make sure that the application is still responsive in all the ways that it will be used. If it is not responsive, you have gone too far, and you must back off some of the settings.

To further reduce the CPU used, msSleep can be increased. Use caution while increasing msSleep because some applications become unresponsive or jerky if this value is increased too much.

Now that you have reduced the amount of CPU that the application is using (while ensuring that the application is still responsive), the system should be able to support more concurrent users.

Some applications may use close to 100 percent CPU regardless of how aggressive you make the polling detection. Keyboard polling is a common problem, but applications may monopolize the CPU in other ways.

If an application is not getting enough CPU, the polling detection is probably too aggressive or the application needs more time to run before being punished. DetectProbationCount and InProbationCount can be increased to lengthen the time it takes to detect that the application is polling. msAllowed can be increased from zero to give the application additional execution time before it is punished for being on probation.

Another way to give the application more CPU while it is being punished is to reduce the value of msSleep. All these possibilities increase the amount of CPU that the application gets, which reduces the number of users who can simultaneously do useful work on the system.

Note DOSKBD is used only for DOS applications. However, Windows applications may also monopolize the CPU by checking the message queue too frequently. This behavior can be modified through the system registry.