20011023: HP-UX vs. Linux for McIDAS use

>From:  "Hoeth, Brian" <address@hidden>
>Organization:  JSFC
>Keywords:  200110231815.f9NIFs119708 McIDAS-X HP-UX Linux

Brian,

>It was certainly nice to finally meet you last week!

Same here!  It is always nice to associate a face with a name.

>Thanks again for all
>your input on HP-UX vs. Linux.  I had a few more questions:
>
>(1)  What's your configuration like up there?  
>  (a)  How many HPs do you have running HP-UX and how many PCs do you have
>running Linux?  Do you have any other O/Ss running? 

Well, what we have running in our office is not very illustrative: 1 HP
running HP-UX 11.00; 7 PCs running RedHat 7.1 Linux.  The better
question would be about the numbers in the Unidata community.  In our
greater community, we have _very_ few HP-UX users (like 1 or 2) and a
_lot_ of Linux users (like >50).  These numbers are not "hard", but
they are illustrative.

>  (b)   What type of PCs do you having running Linux?  

Quite a variety, but typically Dual PIIIs at >= 550 Mhz.  We like to
buy our PCs with at least 512 MB of RAM (1 GB or more is better), and
we also like to buy our machines with SCSI hard disk drives (we find
that the SCSI drives hold up better under heavy use).

>  (c)   Are your Linux machines only used as display workstations or do they
>serve data also?  

Linux machines in the greater Unidata community are used for
everything:  LDM ingest; data decoding (GEMPAK, McIDAS-XCD, netCDF,
etc.); display/analysis; serving (ADDE and DODS).  The machines in our
office do all of the above and are also software development platforms.

>  (d)   Do you run XCD at all?  If so, which workstation (HP, Linux,
>something else?) runs it?

In our office, we typically rely on PCs running Solaris x86 or Suns
running Solaris for McIDAS-XCD.  In the greater Unidata community,
sites are using Linux for everything.

>(2)  You said that the Linux machines have a problem with the sounding
>server?

There is a known problem serving sounding data through the remote ADDE
server on Linux.  By sounding data, I mean data for soundings (UAPLOT,
UALIST, etc) (skew-ts, stuves, hodographs, etc.) and RAOB cross
sections (UACROSS).

>What exactly does this mean?

What happens is that the client that makes a request for sounding
data from a remote ADDE server hosted on a Linux box will get:

pipe read: Connection reset by peer

from things like:

UAPLOT KDNR 12

What is happening is that the socket connection from the client machine
to the remote server is being broken before all of the data is
transferred from the server to the client.  (The OS on the server
machine appears to be the culprit here).  Just how much data gets
transferred is variable, but it appears to be a function of the amount
of time it takes to send the data back to the client.  If the client is
on the same local area network as the server, then virtually all of the
data requested is successfully sent from the server to the client
before the 'pipe read' error.  If the client is on a network that is
distant from the server (distant meaning electronically far), then the
fraction of the data that gets sent can be small enough that the
application making the request (e.g., UAPLOT) may not get enough to
produce a plot.

>This may be an ignorant question, but ... what is the sounding server?

Every McIDAS ADDE server except one (the sounding server) reads data
from local files and sends the data back to the client.  The sounding
server, on the other hand, actually does two server transactions of its
own to fulfill the client's request: the first transacation is to the
POINT server for mandatory level upper air data; the second is again to
the POINT server but this time for the significant level upper air
data.  It is highly suspicious that the only server that itself makes
server requests for data has the problem!

The other thing that makes the sounding serving failure hard to
understand is that NO other operating system shows this problem.  By no
other OS, I include other PC Unix variants: FreeBSD and Solaris x86.
To reiterate what I said in the meeting: I have verified that the
sounding server failure occurs on a wide variety of Linux releases:
Debian, Slackware, SuSe.

I talked with John Benson of SSEC while in Madison about the sounding
serving problem.  He and I came up with a couple of new tests to try to
isolate/identify the problem; I will be working on these ideas in the
coming days.  I still remain hopeful that I can find out why serving
sounding data fails on Linux and fix/work around the problem.  I know
that if worst comes to worst, I can always rewrite the sounding server
and make it read data directly from disk files.  I know that this
approach will work, but rewriting the server will consume time that I
don't have much of (sigh).

>Thanks in advance!

No problem.  Talk to you later...

>Brian Hoeth
>Sustaining S/W Engineering, Lockheed Martin
>Consolidated Space Operations Contract
>Office: 281-218-2240
>Pager: 281-613-1020
>address@hidden

Tom

From:    "Hoeth, Brian" <address@hidden>
Date:    Thu, 25 Oct 2001 07:59:30 CDT
Subject: RE: 20011023: HP-UX vs. Linux for McIDAS use

Tom,

Thanks for all of this very useful info!!!

Brian