HardwareConsiderations

Hardware considerations for running your own ATCS Server:

I have run ATCS servers on a handful of different platforms and here is some of the info I have picked from various "test" set ups. Processor usage values are referencing when the system is "idle" without any extra applications running except the server components (ATCSMon and in the case of the system that also encoded live audio, ShoutCast^?'s streaming MP3 encoder). This information could be used as a baseline for deciding whether the computer you plan to use as an ATCS server will be adequate for data decoding with a low error rate. There are plenty of variables that could some systems to work better or worse than other.

Server 1: dual 400 MHz PII/256 MB RAM/Windows XP Pro This was my first ATCS server and ran with a total of four instances of the ATCSMon.exe program (one BCP, one MCP, one DDE instance, one combination). This setup worked fairly well, but I found that my overall packet error rate went down when I reduced the number of instances to just two. To me, this hinted to the fact that perhaps a little more processor power would help the decoding process. I never noticed exceptionally heavy processor usage, but admittedly was not logging this type of information at the time. This server had two PCI sound cards for ATCS data.

Server 2: 600 MHz PIII/256 MB RAM/Windows XP Pro This was my second system and was used with three instances of ATCSMon.exe (one BCP, one MCP, one combination) and this system seemed to work well. This system had a total of two PCI cards for decoding ATCS data. The error rate was fairly consistent and processor usage tended to be less than 20% most of the time.

Server 3: Athlon 1.7 GHz/512 MB RAM/Windows XP Pro This is my current server. This system has a total of four PCI sound cards installed in it with three instances of ATCSMon.exe (one BCP, one MCP and one EOT data) and runs the ShoutCast^? MP3 audio encoder for encoding audio for the live railroad feed from my website. This is certainly the most robust system but also runs the most applications of any other server. Even so, this system tends to run at less than 10% processor utilization most of the time.

Server 4: 266 MHz Pentium laptop/128 MB RAM/Windows 2000 This system was an experiment really and proved to not have sufficient resources to reliably run as an ATCS server. I ran two instances of ATCSMon.exe (one BCP, one MCP) and the processor usage was typically 60% to 80%. Also, any time other applications were started, the usage would rise to 100%. This system might be usable. Personally, I do not like running any equipment that close to full capacity and decided not to pursue this system as a possible server.

All servers listed were run in what is called "headless" mode by most computer enthusiasts/ professionals, which means that no monitor, mouse or keyboard is connected to the system. All administration work is done via remote control software via the network (either ethernet or wifi) or Internet. For the Windows XP systems (Pro only), I made use of the built in Remote Desktop Protocol feature (sometimes also referred to a Windows Terminal Services). Originally designed for help desk and tech support employees to help customers remotely, it also works very well for administering the server. Once the server and a client are configured, a user on the client computer can simply click a shortcut or run the client app and select a configuration and connect to the server and perform nearly any task that they could do if they were working on the server directly.

For the Windows 2000 laptop, I used a free remote connection utility called TightVNC^? to access this system. The application has to be installed on both the client and the server but it not too hard to setup and is reliable once configured. TightVNC^? works on most versions of Windows and many flavors of Unix/Linux. Recently, a better flavor of VNC has popped up called UltraVNC^?. Seems to work very well and is also free.

Comments/Questions

-- AlabamaRailfan - 29 Jan 2007