Apart from needing to change hooks into the Operating System, does it make sense performance-wise to switch from Red Hat Linux to Windows Server for an A-Shell system which typically has 70 users running programs on it at the same time?

Is there anyone out there with a similar sized user base running A-Shell in Windows? If so, which version(s) of Windows Server are you using and how is performance?

Are there any other things I should be concerned about in considering such a switch?

The customer has more familiarity and expertise with Windows than Linux and would prefer a more consistent operating environment. Virtually every other system they run is Windows-based.

I would appreciate any and all comments. Thank you.

Steven - I won't comment on performance, but I will mention that our fairly large user base includes only a few (about ten) Windows systems larger than 20 nodes, and all of those are 55 nodes or fewer. Most of them are clients of our Italian friends (you remember Enzo and Luca from Porto), who unfortunately don't participate in the forum due to not-so-great English skills.

Given the same hardware, Linux handily outperforms Windows, particularly in larger environments like yours. That said, there are a number of possibly mitigating or extenuating considerations:

1. Windows peer-to-peer should be ruled out of hand for this size system. So we'll assume some kind of server-based model (Windows Terminal Server, Citrix, GoGlobal, ATSD, etc.) for the remainder of the discussion.

Note that these server-based models divide into two completely different categories, what I'll call RDP-style (Windows Terminal Server, Citrix, GoGlobal, etc.) and Telnet-style (ATSD). For the RDP-style (they don't all used RDP specifically, but the concept is the same), the logical screen (within the server) is replicated to the client screen by some pixel-based protocol. As opposed to the Telnet-style case where the server sends characters (bytes) to the client, which is responsible for maintaining its own state and updating the display based on the logic of the character and character-based commands that arrive. The input channel is pretty much the same for the two variations.

2. For RDP-style protocols, you'll need a much bigger server than you would for Linux, or for ATSD, because each connection is essentially a full-blown Windows environment on the server. It's not easy to estimate those memory requirements, but as a very rough approximation, I would take the MEMORY partition size specified in the miame.ini and add about 10MB per telnet/ATSD connection, and about 50MB per RDP-class connection. That would be for plain text applications. Add another 10-20MB for GUI.

3. In the old days, you'd have to squint very carefully at the previous paragraph. Nowadays, you may just get a server with 16GB RAM and not sweat the details.

4. Likewise for CPU - in the Windows environment, all the display operations are GUI/pixel-oriented (as opposed to byte-oriented in the Linux/ssh environment - even when using ATE for a GUI front end), so it takes a lot more CPU power to update displays. So while a single core Pentium could manage your 70 Linux users, you'd want 8 cores or more for the Windows equivalent. (But again, that's no big deal these days, so maybe another meaningless detail not to sweat over.)

5. If you go with an RDP-style environment (as opposed to sticking with telnet), you're probably looking at substantial licensing costs. (On the other hand, maybe all those workstations already have client licenses for other reasons, in which case the additional cost may be minimal.)

6. A-Shell GUI operations in the RDP-style environment are actually simpler than in the telnet/ATE environment, because it acts more or less just like the Windows standalone environment. (The AUI layer which converts GUI calls into ATE messages, relays them to the client, and processes the responses, is bypassed. Instead, there is a more seamless screen-replication layer, which may involve more raw bits being transferred, but for many GUI operations is actually more efficient. Plus you eliminate the latency delays involved when an ATE command requires a response from the client.)

7. For plain text applications, the situation is somewhat reversed. ATSD/telnet style communications are generally much more efficient than the RDP-style remote screen replication when it comes to displaying characters. The one exception is scrolling (like in long DIR or TYPE operation) where, in the telnet case, every byte must be transferred, whereas in the RDP case, the scroll may not be as smooth, but it can effectively skip much of the updating by just resynchronizing the display at the end of the scroll. (Admittedly this is a special case, but I do get asked why scrolling displays take longer with byte-oriented telnet than with bit-oriented RDP.)

Fortunately, if you already have a Windows server at the site, which it sounds like you do, you can probably experiment on it without a lot of investment. Particularly if you're leaning towards the Terminal Server approach and already have it installed on another server, just install a demo copy of A-Shell/Windows on it and make an RDP connection to it. You may be able to get a preliminary feel for the performance just by playing with VUE, DIR, and some of the sample SOSLIB programs. If you're leaning towards keeping the present telnet clients, you'll have to install ATSD, but that isn't very difficult either.

As for version, I'm guessing that most of the existing Windows Server installations of A-Shell are on W2003 or W2008 server, but now I suppose for a new system you would go with W2012 server. (I'm not actually sure if W2012 has been tried, but probably it won't make much difference to A-Shell.)

Caveat: We have a couple of Windows server sites in the vicinity of 50 users, but yours might well be the biggest ever. In contrast, we have many Linux sites with hundreds of users.

My customer has recently switched from a stand-alone Linux server to a Virtual system running on a Windows server under VMWare. There may be performance hits due to the virtualization, possibly because there is only 1 GB of RAM dedicated to Linux. That is shortly going to be boosted to 2 GBs, but your explanation above makes me think that even 2 GBs may be insufficient for 70 users.

Most users already access A-Shell through Citrix sessions (via either AlphaLAN or ATE). So trying to plan for and measure resource usage gets tougher and tougher.

Further complicating matters and performance analysis is the use of the same Windows server for multiple (non-Linux) VMs.

Most of our apps are text-oriented, not graphic. (Only 1 ATE invoked app is GUI-oriented.) If we did migrate A-Shell to a shared Windows platform, is it possible to connect via Telnet/SSH? Is it sensible? I don't really understand how connections are made to A-Shell under Windows. Are AlphaLAN and ATE still necessary?

And since many sessions are already RDP-based (via Citrix), does it make sense to have an RDP connection within another RDP connection? (That is, the outer connection displays the Windows desktop on the user's physical PC's screen, and the inner connection displays an A-Shell screen in a window on the desktop?)

I need a better understanding of A-Shell under Windows.

Sorry, I somehow missed your follow-up message until now.

I'm unable to say whether 2GB will be sufficient for the 70 users - you'll just have to try it, and look at the Performance Monitor to get a sense of whether it is memory-bound or not.

On the RDP within RDP question: there's no need for such nesting. If there is an RDP connection from the client workstation to the server, and the server has A-Shell on it, then you just launch A-Shell directly within that environment. From A-Shell's perspective, it will be running locally on the server; the fact that Terminal Services is replicating the virtual screen to the remote workstation is of little concern. RDP sessions may be considered similar to just opening multiple A-Shell windows on the console, except that each one belongs to a separate login and has its own, albeit remote, keyboard/monitor.

However, the comparison between RDP and Telnet (discussed in my prior post) still applies. (SSH is not currently supported by ATSD.) In theory, the Telnet behavior/performance between the Linux and Windows servers should be similar. What is harder to predict is how RDP and Telnet will stack up. But as I said previously, it's not hard to set up a test of both at the same time for a somewhat-real world comparison. (A more real-world comparison would require getting 70 users of each time connected.)