This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: karl <address@hidden> >Organization: UCAR/Unidata >Keywords: 200106251950.f5PJot107677 >We are in fact running NFS3 and a single machine will be running 10-12 >copies of garp at once. The clients are pentium 2 windows machines. > >-------------------------------- >-Karl Brosius >-Unix Administrator >-Space Physics Research Facility >"Implement Technology" > Karl, The biggest resource that Garp or NMAP would be using is the amount of memory used for creating image loops. If you have 10-12 users all generating loops of images on the same machine as you are using for your LDM ingest and data decoding, then you are probably talking about a 2-4 processor server with at least 1GB of RAM per CPU. If you offload the LDM and decoding to a separate machine, you can lessen the impact of users on your data decoding and processing needs. NMAP2 allows the users to have up to 8 briefing/looping windows per session, so one copy of the program has the potential for using a lot of resources if each of the windows has loops of data being displayed. With users moving X displays over the network, you probably want to have your own network switch so that the traffic is kept within the lab, rather than having the displays going out onto the campus network. As you know, GEMPAK uses an 8 bit default X display, so you would want to verify that any X server that the PC's are using can provide that. If your PII's are under the 200MHz range then the ability to rendor the images for loops may turn out to be the limiting factor. You might want to test the configuration before making big purchases. Steve Chiswell