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

Re: 19990525: Linux LDM

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.

  • Subject: Re: 19990525: Linux LDM
  • Date: Wed, 26 May 1999 15:37:33 -0600 (MDT)
On Wed, 26 May 1999, Unidata Support wrote:

> 
> ------- Forwarded Message
> 
> >To: Unidata Support <address@hidden>
> >From: Mark Tucker <address@hidden>
> >Subject: Linux LDM
> >Organization: .
> >Keywords: 199905261945.NAA13673
> 
> 
> Hi, I'm planning on upgrading our ldm and decoders shortly.  I noticed
> that there is no ldm.tar.Z linked from the ldm setup web
> pages.  I ftp'd in and found that the only ldm binary for Linux was 
> 
> /pub/binary/linux_2.2-i686/ldm-5.0.8.tar.Z
> 
> Is this binary specifically for Linux kernel 2.2?  

Hiya,

Yep it is.

If it is is there a
> compiled ldm for those of us still using the 2.0 series of kernels?  

No, I don't have a platform to compile the 2.0 series   The Linux release
was just created last month and UPC already moved to 2.2  But there is a
Linux source release at:

/home/ftp/pub/ldm5/linux.tar.Z

I didn't want to make a linux binary because of the many different Linux
configuration.  If you build the source then the configurations are likely
to be correct.

> What is the difference between 2.0-i686 and 2.0-i586?  We're running our
> ldm on a PII-400.

For the LDM, it doesn't matter. I believe the i-686 and i586 directories
were made for other packages. ie udunits


> 
> 
> Also, I noticed an e-mail while searching the support archives from David
> Wojtowicz about some of the memory/caching problems he has found under
> linux (Subject: Re: 19990520:  Linux LDM memory problem).  I just thought
> I'd confirm some of the issues he mentioned and point out some of the
> things I have observed related to this.  
>     We run with a queue of about 400MB for our ldm for quite a while.  
> Stopping the ldm definitely takes some time and disk writing for
> everything to exit completely. This generally takes several minutes for
> every thing to settle down.   Running "ldmadmin restart" has never
> worked correctly as far as I can remember because of this (at least, that
> has been my assumption).
>    Because Cirrus has ample memory (512 MB) there is enough room for the
> file cache and buffer to co-exist with the other processes.  I think this
> is the main reason that we have not seen some of the delays in working
> interactively on the ldm server that he cites.   
> 
I agree with your diagnosis, maybe the Linux folks will fix this problem.
Solaris x86 has the memory management correct so I know it can be done. 


Robb...


> Mark Tucker
> Information Technology
> Lyndon State College
> address@hidden
> 
> 
> 
> ------- End of Forwarded Message
> 

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