Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reducing Terminal Services Resource Usage for Dos Apps 1

Status
Not open for further replies.

colttaylor

Programmer
Aug 20, 2002
117
0
0
US
I had been running some of my older dos (turbo pascal) applications in Terminal Services and finding the performance to be less than I would want. After many attempts, I found the following changes which not only made my apps run at a usable speed, but also left the terminal server's resources practically untouched. Following these changes one of my customers is running twelve dos applications in six terminal server sessions on a 600mhz PII win2k box with 512m ram and the cpu usage rarely exceeds 2%. Here is what I did...

I added the following procedure to my general library...

procedure make_app_idle;
var regs : registers;
begin
regs.ax := $1680;
intr($2f,regs);
intr($2f,regs);
end;

then everywhere that my applications waited for a keystroke in a code such as...

ch := chr(0);
repeat
if keypressed
then begin
ch := readkey;
if ch = chr(0) then ch := chr(128 + ord(readkey));
end;
until (ch <> chr(0));

...I called the new routine as the else branch of the if keypressed statement. For example...

ch := chr(0);
repeat
if keypressed
then begin
ch := readkey;
if ch = chr(0) then ch := chr(128 + ord(readkey));
end
else make_app_idle;
until (ch <> chr(0));

...When I did this to my old applications, their consumption of resourses (cpu time as measured in task-manager's performance tab) went from 100% to 2% and their functioning speed (when multiple old applications were running simulataneously in multiple terminal server sessions) went back to what I am used to on dedicated desktop machines.

Other things that helped...
Because my dos applications pre-date windows with its on-screen clock and screen saver, my programs all implemented these features themselves. In the keystroke detection loop which I showed above, I would also write the current time to the screen and track how many seconds had passed since the last keystroke. Once that seconds counter reached 60, I would clear the screen and then wait in another keystroke loop, waiting for a key press, indicating I should redraw the screen. I removed these features as an early attempt to lower my resource consumption and although the server's cpu was still pegged to 100% after these changes, the applications did run noticably faster.
I also had some extra screen i/o hidden in my crt-based windowing library. (Dos applications often reuse portions of the 80x25 text screen by clearing rectangular regions, enclosing them with lines or colors, and rending new text within the &quot;window&quot;). My library for doing this was actually writing out strings of spaces to clear the rectangular area, then writing the space-filled strings again, this time with line-draw characters embedded, and finally writing out the text contents of the &quot;window&quot;. By eliminating the first set of strings (those which cleared the area), I got another perceivable performance boost.
A funny note to add here. That same crt-based windowing library used the turbo-pascal sound() command to generate a cute &quot;twerp&quot; sound as the window opened. Under terminal services, this sound got broken up and slowed down, making it sound like machine-gun farting. For reasons not involving performance or resource consumption, that code was also removed.
I know it seems a little unusual to be investing this kind of time on dos applications, but these are complex and fully mature systems which represent conservatively 100k man-hours of development and 100m cpu-hours usage in the field. Upgrading them to windows might be the right thing to do, but throwing away that kind of stability for the sake of a prettier user interface would be INSANE!
Hope there are other walking antiques out there who can benefit from this information.
Peace,
Colt.

NOTE : I am posting this same tip in the NT and WIN2K forums as it may be of interest to non-pascal application authors.
If it's stupid but it works, it isn't stupid
 
Extract from Ralph Brown's Interrupt List:

MS Windows, DPMI, various - RELEASE CURRENT VIRTUAL MACHINE TIME-SLICE
AX = 1680h
Return:AL = status
00h if the call is supported
80h (unchanged) if the call is not supported

Notes: Programs can use this function in idle loops to enhance performance under multitaskers; this call is supported by MS Windows 3+, DOS 5+, DPMI 1.0+, and in OS/2 2.0+ for multitasking DOS applications. Does not block the program; it just gives up the remainder of the time slice. Should not be used by Windows-specific programs. When called very often without intermediate screen output under MS Windows 3.x, the VM will go into an idle-state and will not receive the next slice before 8 seconds have elapsed. This time can be changed in SYSTEM.INI through &quot;IdleVMWakeUpTime=&quot;. Setting it to zero results in a long wait.. This function has no effect under OS/2 2.10-4.0 if the DOS box has an &quot;Idle Sensitivity&quot; setting of 100

See Also: AX=1689h - INT 15/AX=1000h - INT 15/AX=5305h -


I've used this routine a couple of times, and it works quite well on fast machines. One question though, do you call that interrupt twice for a specific reason or is it just a typo? Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Thanks for the additional documentation!
As for calling the interrupt twice...
I do call it twice, but this could be a typo from the person who gave me the code (A truly great programmer).
I shared it to the forum so that others could use it,
but prior to your documentation, I was ignorant of how
it worked. I shall run some experiments with using
one interrupt call versus two and post the results back here in a couple days.
Peace,
Colt.
If it's stupid but it works, it isn't stupid
 
I've used this for years. I call it Twiddle. In any polling loop of any kind that's not time critical I call it if it doesn't have anything to do. Note also that it helps keep windows from deciding the application is idle and starving it of CPU cycles. Unfortunately, it's not 100% at this. Windows still doesn't always get the notion that a background window should continue to get CPU time and give it back if it doesn't want it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top