We are migrating from a Netware environment to Windows 2000. We have the win2000 Service loaded and running on one Win2K server, REVPARAM all set to ServerOnly=1, with Terminal Server loaded on another Win2K server. Our Clients log in to the terminal server through the terminal client, and launch AREV by double-clicking an icon on their terminal desktop which points to the AREV application on the other win2K server. AREV loads fine, but about one minute into the actual session AREV appears to lock up. We can access and run AREV fine through a regular client session NOT utilizing Terminal Server.

It is just whenever we launch it through the icon on the desktop of the Win2K Terminal Server that we hang up. Anybody have any suggestions?

Are there recommended configurations for running AREV through Terminal Server?

Thanks!

If AREV is simply hanging using a solitary session (even with indexing disabled) then it could be a problem with memory configuration - try running AREV in full-screen mode without expanded memory and see if it works under these circumstances.

Optionally, assume it's not hanging, but just running very slowly during login, and again as soon as the indexing cuts in first time. Could be due to the CPU usage peaking - have you run a CPU utilization test to check the load? If this is the case then set your idle sensitivity to 80% on the Windows shortcut, and set AREV to yield time to Windows in the SYSPROG environment configuration.

AREVFIX.COM was issued with Citrix to handle similar problems.

There is a third party utility product called TAME which also aims to remedy this.

There is also another utility available that we cannot mention that installs into AREV directly.

Problem is that when AREV runs the RBASIC statement INPUT,-1 there is a tight loop to poll for keyboard activity. The AREV code here was designed for DOS - so it's single threaded - so AREV uses 100% of CPU waiting for keystrokes. Fine in DOS but not so good in Windows. This also seems to happen during indexing updates (which can also be interrupted by keystroke activity and thus must be polling). The YIELD() statement was introduced to handle this to some degree within AREV.EXE

Another facet to the problem is that Win 95 and 98 and NT and 2000 all timeslice differently, meaning that using YIELD() is ok for Windows 9x, but is of less benefit in NT or 2000. AREV 3.12 dates from 1995 or thereabouts, so does not handle the later OS's and Winframe/Citrix/Terminal Server style programs very well.

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezz

Is any of the above an isue with OI.

Barry

Barry,

Most windows executables (16 bit or 32 bit) don't suffer from the problem a DOS executable potentially does. If coded really badly, they potentially could, but Windows' keystroke polling is usually governed by Windows, and this means you can load up multiple programs at once, each with a smaller CPU timeslice.

We've often seen terminal server and Citrix Winframe / Metaframe choke at about fifteen to twenty users per box. Thinking out aloud, Pentium III 800 mHz / 15=53 mHz plus a timeslice penalty, which takes you to about 486/50 performance per session. As for RAM, 128 mB / 5.6 mB for a Winword 2000 session gives 22 users before you start paging to disk. Subtract the screen buffer handling per user and you start to page sessions to disk at around 20 users. On server boxes with lower spec. than a 800 mHz with 128 mB RAM the concurrent user count is obviously much lower.

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezz .. you done good on this one ;-D

Don Miller

Thanks, Don.

Just to clarify,

We haven't often seen OI used in the Terminal server setting and so can't comment on its performance in this setting. Hence the Winword 2000 example. There are other factors in all this (OS overheads, network bandwidth etc.) but as a coarse indication the numbers are probably useful as a guide to reasonable server/user ratio.

The only way to get AREV's CPU utilization down is if the keystroke handling routine performed the code to yield time to windows around each INPUT,-1 statement. The problem spots in AREV's native routines include the menu code, the indexer code, the input.char code, based on observations.

The timeslicing under different versions of Windows means AREV would need to yield() once for Win9x and about twenty times under NT. Under Win2000 it's more like 80 times. However, because the RBASIC code overhead surrounding the RBASIC yield() often increases the CPU activity and timeslice, there's a nasty Catch-22 involved!

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...