This chapter outlines several alternative options for installing and using SoftWindows on a UNIX network.
It also discusses the factors affecting the performance of SoftWindows and tells you how to tune them effectively.
For information on how to install SoftWindows, Windows applications, and MS-DOS applications in various configurations, refer to the following sections of the SoftWindows documentation.
SoftWindows – see Chapter 3, “Installation.”
Microsoft Windows applications – see “Using Windows” in the SoftWindows 95 for UNIX User's Guide.
MS-DOS applications – see “Using MS-DOS” in the SoftWindows 95 for UNIX User's Guide.
Install SoftWindows on the local workstation (15 MB minimum per workstation).
Create each user's hard disk file on the local workstation (180 MB minimum per user).
Install applications on the local workstation.
Run SoftWindows on the local workstation.
This option provides the best SoftWindows performance since the user's network does not play a major role. However, one of the disadvantages is that SoftWindows can take up a significant amount of total hard disk space since each user needs to have SoftWindows, Microsoft Windows 95, and applications installed on the local hard disks.
The best SoftWindows performance because all files are accessed from the local hard disk, and there are no network load issues involved in running SoftWindows files.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Complete control over environment.
Stand-alone operation – do not have to rely on the operation of the network.
Install SoftWindows on the local workstation (15MB minimum per workstation).
Create each user's hard disk file on the local workstation (180 MB minimum per user).
Install applications on an NFS server.
Run SoftWindows on local workstation.
This option generally provides lower performance than Option 1 because SoftWindows has to access the network when running each application. However, this allows the user to have one installation of each application, thereby saving hard disk space. Furthermore, upgrading an application only needs to be carried out once on the NFS server instead of on each local workstation as in Option 1.
Fast SoftWindows performance.
If the NFS mount is fast, this option could be as fast as Option 1.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Requires less local hard disk space than Option 1.
Application and user files can be centrally managed and upgraded from the NFS server.
Install SoftWindows on the local workstation (15 MB minimum per workstation).
Create each user's hard disk file on the local workstation (180 MB minimum per user).
Install applications on a PC LAN file server.
Run SoftWindows on the local workstation.
This option generally provides lower performance than Option 1 because SoftWindows has to access the network when running each application. However, this allows the user to have one installation of each application, thereby saving hard disk space. Furthermore, upgrading an application only needs to be carried out once on the PC LAN file server instead of on each local workstation as in Option 1.
Generally good SoftWindows performance.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Requires less local hard disk space than Option 1.
Application and user files can be centrally managed and upgraded from the PC LAN server.
Applications can be shared with the users using real PCs and SoftWindows PCs on the PC LAN server.
Typically slower than Option 1 or Option 2.
Requires at least 200 Mbytes of hard disk space on each local workstation.
The SoftWindows software updates have to be applied to each local workstation.
Accessing application and user files from a typical PC LAN via PC networking software is generally slower than accessing the same files from a typical NFS server.
Only one local SoftWindows instance at a time can use the applications on the PC LAN file server; that is, multiple SoftWindows instances and/or processes on the same workstation cannot simultaneously access the PC LAN file server.
Install SoftWindows once on an NFS server (15MB minimum).
Install applications on an NFS server.
Run SoftWindows on the local workstation via NFS (no local SoftWindows files installed).
Create bootable SoftWindows hard disk file for each user on the NFS server (180MB minimum per user).
This differs from Option 1 in that all of the SoftWindows files are installed on the NFS server instead of on the local workstation.
Saves local workstation hard disk space since only the server needs to have a copy of the SoftWindows and application files.
If the NFS server access is at least as fast as local hard drive access, this option could be nearly as fast as Option 1.
SoftWindows and application updates need only be applied to the server.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Local workstations may be diskless.
Install SoftWindows once on an NFS server (15MB minimum).
Create each user's hard disk file on the local workstation (180 MB minimum per user).
Install applications on an NFS server.
Run SoftWindows on the local workstation via NFS.
Typically used when local workstation hard disk space is valuable, but performance is a major consideration. This option is the same as Option 4, but with some possible performance improvements as a result of having hard disk files installed on the local workstation.
Optimization of the smallest local workstation footprint with the best performance.
SoftWindows has access to the local workstation's devices, such as floppy disk drives, CD-ROM, and comms ports.
Install SoftWindows and each user's hard disk file on a remote UNIX workstation (15 MB + 180 MB minimum).
Install applications on a remote UNIX workstation.
Remotely run SoftWindows on the remote UNIX workstation, but display it on the local workstation via an X Server.
This option enables X terminals and UNIX workstations with X Windows to run SoftWindows via an X server display. SoftWindows and the applications are installed on the remote UNIX workstation, and multiple instances of SoftWindows are run on the remote UNIX workstation and displayed via an X server on the local workstation or X terminal.
Can be used with X terminals.
Does not use any local workstation space for SoftWindows or application files.
SoftWindows and application updates need only be applied to the remote UNIX workstation.
The performance of the local workstation is impacted only by the X server display operations and not the SoftWindows or application executables.
The performance with an X server display may be significantly better than with the other options on the same workstation.
The performance seen on the local X server display is a function of the performance of the remote UNIX workstation running SoftWindows, the network performance, and the local workstation's load in handling X server functions.
Accessing SoftWindows files over the network may be slow.
Running multiple copies of SoftWindows on a single remote UNIX workstation can quickly reduce the performance of each of the local workstations on their local X server displays.
Only one instance of SoftWindows can access PC networking at a time on a single workstation. This means that when there is more than one instance of SoftWindows running, only one instance can use the PC networking.
One possible solution to this networking limitation would be to store any data or applications files on an NFS server or on the remote workstation, and then use FSA drives to concurrently access the files from multiple instances of SoftWindows running on the same or multiple UNIX workstations.
SoftWindows will typically only see the remote UNIX workstation's devices and therefore cannot directly use the local workstation devices, such as floppy drives, CD-ROM drives, and comms ports.
Only one user can access a server device at a time.
The recommended amount of memory for workstations running SoftWindows is 64 Mbytes or more. It will run on 48 Mbyte machines but performance may be suboptimal.
To run Windows applications under SoftWindows the recommended amount of PC memory is 16 Mbytes, as on a real PC. Certain resource-intensive applications may require more memory for optimum performance.
Allocating too much PC memory can reduce performance in some circumstances, depending on the amount of physical memory in the machine, and the other processes running on the machine, since swapping may result. We recommend that you increase the PC memory gradually until any resulting increase in performance levels off. Adding more PC memory after this point could reduce performance.
On 48 Mbyte machines, performance may be improved if you reduce the PC memory below the default of 16 Mbytes.
SoftWindows uses host memory to support the Pentium emulation in addition to the memory used to emulate PC memory. It is possible that adjusting the amount of host memory dedicated to the Pentium emulation can improve performance. By default, the Pentium emulation is allocated the maximum value of 8 Mbytes, or 1024 code buffers. You can change this by setting the environment variable MaxCodeBuffers to a minimum of 3327 (25 Mbytes of memory).
The Pentium supports paging, allowing pages of data from memory to be swapped to secondary storage. If your host machine has limited memory and you know that you are going to have to endure a certain amount of swapping, you have the choice of either getting Microsoft Windows to handle its own swapping (by setting a lower amount of PC memory) or allocating enough PC memory to SoftWindows to alleviate this. In the second case, the host machine handles the swapping.
Although a diskless node has its own memory, it uses the server for its operating system. Also, because the node's disk is shared with the server, paging is carried out by the server, not by the diskless node. This will have a compounded effect if a user tries to run more than two versions of SoftWindows at a time. Refer to “Physical memory” for more information.
The configuration of the user's network also affects the use of SoftWindows on a diskless node since SoftWindows will need to access the network for everything; this could cause a degradation in performance, particularly if the network is slow and unreliable.
When SoftWindows is actively running a PC or Windows application it will attempt to use 100% of the UNIX host's available CPU – just as the application uses 100% of a real PC's Pentium CPU cycles.
If you run several SoftWindows sessions concurrently on the same machine, they will share the host's CPU resource. For example, if two SoftWindows sessions are running simultaneously on the same machine, each will use at most 50% of the host CPU resource; they will therefore run at half speed when they are both active.
Note: SoftWindows will use its idle detect feature when a session becomes inactive. This means that if you have two sessions on one machine, and one is idle, then the other will run at full speed. This is achieved by means of the SoftWindows WinIdle utility; refer to “WinIdle.”
The performance of SoftWindows is reduced when it is displayed remotely because display data and input from the keyboard and mouse has to be transferred over the network.
A 256-color bitmap can be quite sizeable in terms of the amount of data which must be transmitted. A remote display may also affect the networking component of SoftWindows since, for particular protocols on particular platforms, SoftWindows networking sees all the packets that the host machine sends, including any packets resulting from having a remote X display.
For best performance use an 8-bit graphics card.
There may also be an issue when using Microsoft Windows with 256 or 16 colors. There have been some instances of a graphics card having a problem with one color setting while working fine with the other. An example of this is the Sparc ZX card. In tests, SoftWindows ran slower when in 16-color mode than in 256-color mode. It should be noted that the results were very host-specific.
Another option which produces a performance improvement is the use of the -backing_store option with SoftWindows. This option makes use of the backing store facility if it exists on the user's machine.
If, while using the -backing_store option, SoftWindows suddenly stops refreshing the screen, then the problem may be the X server. If the server runs out of memory, the backing store facility simply disappears. If SoftWindows has not refreshed the window since you launched it, you may have to restart your X server with an option enabling the backing store feature.
The larger the SoftWindows screen size selected, the slower SoftWindows will tend to run.
If the application displays larger bitmaps as a result of a larger screen size, this results in much more data being sent to the X server, which can degrade performance.
If the window is too small, the application does its own clipping within the emulation. For example, too small a window size can cause scroll bars to be displayed. This can also impact performance.
You may wish to select various screen sizes to see which best suits your application. Beware of having screen sizes which occupy the entire X display or even are partially off screen, since this is known to severely degrade performance with certain window managers because of the extra clipping work required on each X request.
SoftWindows can be run on an X terminal connected to a UNIX server. Note, however, that the areas of concern highlighted in the “Local display versus remote display” and “Physical memory” sections apply to the use of SoftWindows on an X terminal.
Running an application on an X terminal uses up some of the resources of the UNIX server to which it is connected.
Also note that Windows 95 performs numerous offscreen bitmap operations which SoftWindows delegates to the X server, and this uses the local X terminal memory. The amount of physical memory an X terminal has can impact these types of operations. With the X server using some of this memory as well, you may need to add more physical memory to the X terminal. The amount each terminal requires is very host-specific, and also depends upon the X server being used.
For FSA drives where the user knows that all files are DOS/Windows files in standard 8.3 format, FSA file access can be improved in certain circumstances. For example, if you are accessing an OS/2 file system from Windows 95, use Case Insensitive as your preferred case. For more information refer to “Mapping filenames on an FSA drive.” If you are accessing an OS/2 file system from Windows 3.11, use the NET USE /CS command to disable the filename mapping facility, since it would be unnecessary on an 8.3 file system. For more information refer to “NET USE.”
If SoftWindows is being run on a multiprocessor host, a performance improvement may be seen by ensuring that SoftWindows runs on a different processor than the X server. If the host is to run multiple SoftWindows sessions, it would be best to run each session on a different processor if sufficient processors are available.
Due to the mechanism used by SoftWindows to provide PC LAN connectivity, users may experience a slight degradation of SoftWindows network performance on busy networks. Where possible, SoftWindows PC networking drivers are passed only the network packets required by the PC network client software. However, if the SoftWindows user requires UNIX connectivity using TCP/IP, the SoftWindows networking drivers will also receive the host's own TCP/IP traffic which must be rejected. This extra filtering can cause a slight increase in workload on the PC emulation.
It is recommended that when SoftWindows-based TCP/IP client software is used, the SoftWindows session should not be displayed on a remote display. Displaying remotely increases the overall network load on the PC-based TCP/IP stack.
In general, the SoftWindows networking drivers are passed the same amount of information as would be passed to a real networked PC and are subject to the same environmental conditions. Extra CPU resources or memory will not solve problems caused by a poorly structured, badly designed, or incorrectly routed local area network.
SmartDrive causes a performance degradation of 2%–5%, and so it is recommended that you do not enable it.
The SmartCopy utility can cause a delay when switching to the SoftWindows window from another X application after selecting a large amount of data due to the time taken to copy the data selected in the X application to the Microsoft Windows clipboard. Depending on the amount of data involved, this can take a second or two. It is highly recommended that you leave SmartCopy running at all times.