[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NOAAPort data server x86 configuration (fwd)


===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Sat, 14 Oct 2000 00:34:23 -0400
From: Jim Koermer <address@hidden>
To: address@hidden
Subject: Re: NOAAPort data server x86 configuration

I've remained somewhat silent on this issue, since I'm probably a lonesome
voice in the wilderness and perhaps the only Unidata FreeBSD site--at least,
I don't know of others.

We've been using FreeBSD for several years. It's been virtually trouble
free. Installations and upgrades can usually be completed in much less than
an hour. We currently use it on eight machines ranging from 486/DX (until
Monday, it used to do Alden ku-band DDPLUS LDM ingest) to a dual-PIII-600
faculty machine.

Our biggest server and workhorse is a Dell PowerEdge 2300 with dual
PII-400MHz processors, 1 GB of RAM, 36 GB of internal disk space, a 120 GB
external RAID system, and a DAT tape backup.  We use this to do all of our
web production, acts as our real-time interactive web server, runs WXP,
McIDAS, and GEMPAK. On this system, we have online for various research
products text and graphical interactive access to all surface and upper air
observations in raw and decoded form for the past 2+ years.  For our primary
web site, we build roughly 25 animations (mpegs and/or animated GIFS) per
hour including large 72-hour satellite loops and thousands of GIFs per day.
It also runs LDM and ingests/decodes for McIDAS and GEMPAK. Acts as an
X-server for up to 16 PIII/500MHz NT machines to run WXP, McIDAS-X, and
GEMPAK and heavily uses NFS and SAMBA (for CD-ROMS) copied to hard drives.
Most recently we set up our DIFAX products ingest on this machine with the
demise of ku-band from Alden and we are now capturing and printing all the
products that we used to get from ku-band.  I've also tested direct LDM
ingest of our voluminous NOAAPORT data from NWSTG, GOES-E and GOES-W
channels (simultaneously)--the hard drives added about 6 GB of data in an
hour with no noticeable degradation in performance. As the AMS' primary
backup site for DataStreme production, we continuously generate a large
number of text and graphical products each hour. We used to do this on our
RS6000, but recently moved it over to this server for improved reliability
and tremendous speed improvements in generating the products (a few minutes
versus nearly an hour). Except for the times when I've built some large
~3-week satellite animations of tropical systems, I've never seen the
machine really getting anywhere near capacity. It really seems to handle
multi-tasking quite well.

In a matter of minutes, one of our  PIII-500MHz machines with 256 MB can
back up most of the PowerEdge functions. This machine also works
continuously as a McIDAS ADDE server and as an interactive web server for
generating GINI imagery products.

We still use an RS6000 for our primary web and LDM relay server, but not for
much else. When it dies, it's gone. IBM doesn't even want to talk to you
unless you have a highly overpriced service contract, even after you
purchased software upgrades from them. OS upgrades on that machine were
always a pain and not always successful. It has been a reliable machine and
is good at handling network traffic. However, we would probably move
everything over

We have just had tremendous success with FreeBSD. Most our our main campus
servers are also now Dell PowerEdge Servers running FreeBSD. They handle all
academic computing duties from all e-mail to providing individualized
"remote" drives to students/ faculty logging on to PCs in their offices or
public clusters. The hardware has been solid and the software has performed
superbly.

Several years ago, I wanted to go with LINUX, but my IT folks convinced me
to go with FreeBSD--I am very happy that I did. We have been able to manage
all of these and 17 NT boxes and several other PCs without a full-time or a
part-time system administrator. An IT colleague provides assistance from
time-to-time (usually a few hours per month), but we don't have to spend
much time troubleshooting the BSD boxes or OS. I wish NT worked nearly as
well--I'm just glad that we don't depend on those machines for 24-hour
operations.

My lonesome vote is for FreeBSD, although Robert did indicate that it was
supposed to do well under heavy loads. I can confirm that.

                                                    Jim
--
James P. Koermer             E-Mail: address@hidden
Professor of Meteorology     Office Phone: (603)535-2574
Natural Science Department   Office Fax: (603)535-2723
Plymouth State College       WWW: http://vortex.plymouth.edu/
Plymouth, NH 03264

address@hidden wrote:

> I believe that this tendency for Linux to bog under heavy loads
> was/is a known thing.  I lost the URL but there was Linux
> backer that did some NFS, CPU, i/o, etc test of Solaris x86,
> different Linux kernels, and the BSD's (Free and Net).  His tests
> confirmed that the Linux distribution did indeed "bog" down
> under heavy load.  There was discussion that newer Linux kernels
> were expected to fix the problem, and maybe that has happened
> with some of the latest development kernels.  His results
> did indicate what many people thought, that the BSD's were
> the fastest of the bunch, although Solaris as expected did well
> with heavy loads.
>
> Heavy loads is a relative term. We run the LDM, the McIDAS and GEMPAK
> decoders, another set of GEMPAK dcgrib decoder that decodes data ftp'ed
> from NCEP, serve one McIDAS or GEMPAK session, and hosts a web page that
> produces McIDAS/GEMPAK inages with CGI scripts..all on one Solaris
> x86 machine(we also have a Sun Ultra 10 clone at another location that
> does the same thing).
>
> Robert Mullenax