RE: LDM Archive Machine

ALL,
        My original post was not intended to start a holy war of Linux vs
Solaris.  We have been down that road and know which side IBM is puttting
1 Billion Dollars into.  Hehe :)

        Anyway, I realize that if LDM servers would stay on-line and
internet connections would stay on-line and people would not run IIS which
take down OC3 lines, we would not need an archive.  There are reasons
other than Linux stability that make an archive needed in my opinion.
Your milege may vary...

Later,
        Daryl

On Tue, 18 Sep 2001, Arthur A. Person wrote:

>On Tue, 18 Sep 2001, Robert Mullenax wrote:
>
>> Daryl,
>>
>> I wish you luck in your endeavor, but IMO, and based on my tests and
>> observing the e-mails about LDM through the years, the problems with
>> LDM crashing/kernel problems..etc is due to Linux itself.  It certainly
>> has the well known problem of crashing under heavy load, whereas
>> Solaris Intel is virtually bulletproof.  Not to pick on Gilbert,
>> he's been a great help to me over the years, but his LDM just crashed
>> again..he hates Solaris but I am 99.9% sure these bouts he has would
>> go away if he'd switch.
>
>Linux may be a little green yet, but, in my opinion, it's poised soon to
>be the OS of choice for server systems.  Our ldm relay system (no
>decoding) is RedHat 7.1 with LDM 5.1.3 and it NEVER quits.  Runs
>flawlessly (ignoring configuration issues).  I also have a second system
>running RedHat 7.0 that does decoding and file serving.  It too runs
>nearly flawlessly (I can think of one case where it had a problem a couple
>months ago that required a reboot, but it's also 7.0... I need to
>upgrade).  I'm sure Gilbert's problems will be found to be some subtle
>configuration issue or perhaps a hardware issue, but I don't believe Linux
>is fundamentally the problem.  Regarding Solaris, at this point I'd never
>go back.  Solaris is solid but, in my opinion, it's falling behind in
>development and overall utility.
>
>My 2 cents.
>                                     Art.
>
>
>
>> At my previous job at NMSU/NSBF we have been
>> running
>>  the LDM plus all of the GEMPAK AND McIDAS decoders plus a web server and
>> GARP/McIDAS sessions on a single CPU Gateway PC running Solaris for over two
>> years now.  The
>> only problems that have ever occurred were related to hung gplt routines
>> caused by my CGI scripts.  These occasional to frequent crashes that
>> LDM-Linux
>> boxes all seem to have simply don't occur or rarely occur with Solaris
>> Intel.
>> Performance is fine as well..and as CPU usage approaches 100% you'll see
>> Solaris
>> surpass Linux.
>>
>> Anne can correct me on this but Unidata is running an incredible amount of
>> stuff on their dual PIII Solaris machines and have never had a problem.
>>
>> Linux has it's place, but with this particular application (the
>> LDM/decoders)
>> it simply fails more often than it should.  If you continue to have problems
>> I would suggest that you at least look into Solaris x86.  Solaris will run
>> on the Athlon, depending on the particular motherboard.  We had a network
>> problem at NMSU/NSBF which caused us always to lose a bunch of data.  I
>> eventually
>> arranged for our feed to set his ldm to 5400 seconds as I did mine to cut
>> down on that a bit..then when I needed data I put out a call on this e-mail
>> list or the needdata list.  There are many people archiving out there.
>>
>> In any event, good luck, to you.
>>
>>  /**
>>   * Daryl Herzmann (akrherz@xxxxxxxxxxx)
>>   * Program Assistant -- Iowa Environmental Mesonet
>>   * http://mesonet.agron.iastate.edu
>>   */
>>
>
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  person@xxxxxxxxxxxxxxxxxx, phone:  814-863-1563
>

-- 
/**
 * Daryl Herzmann (akrherz@xxxxxxxxxxx)
 * Program Assistant -- Iowa Environmental Mesonet
 * http://mesonet.agron.iastate.edu
 */


  • 2001 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the ldm-users archives: