I cannot confirm that. One thing to keep in mind is the setup I use.
First, each terminal runs Windows XP. I allocate 512MB of RAM to each terminal. In this case, I noticed some slowness a few weeks ago, so I allocated an additional 256MB of RAM to this specific terminal. A few days ago, Windows Update downloaded and installed some patches, but I forced the server to not reboot (I prefer to have reboots done over the weekend, as the server take about 30 minutes to come back up and restart all the terminal machines.) After that I noticed additional CPU usage on the server. Logging into VMWare, I noticed that the FRT machine was non-responsive. I stopped MT and restarted it. Live Updated asked me if I wanted to update. Suspecting a memory leak in MT, I installed the update and restarted MT. However, Live Update demanded to update again and thought it was still on the old version. At that time I tried to shut down the terminal but the OS locked up. Server CPU and HDD usage was high at the time, but still manageable. I logged into the remaining terminals and updated MT with no problems, then forced a shutdown on the FRT terminal and restarted the server. At this point the server has recovered and is using nominal CPU and RAM (about 5% - 10%, which is what I usually see). All terminals are working properly.
As a result, I cannot say the FRT was the cause, but more likely a patch issue, a memory leak in MT, the Vmware client OS (Win XP) having issues, or the likes.
For a user who is running a dedicated WinXP machine, with 512MB of RAM or more, I doubt this will be an issue. My setup is slightly more complex and compounded by the fact that the VMware clients share CPU, RAM and swap on the primary server, so it's hard to compare. |