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

20000809: 20000808: quick update before going to bed



Tom,

When upgrading to ldm 5.1.1 from ldm 5.0.x, ,you must make a new queue
since the old queue format is not compatible with the new program.
Similarly, the queue structure for 5.1.2beta is also different.

Steve Chiswell



>From: "Thomas L. Mote" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200008092055.e79KtdT03050

>
>Tom:
>
>I saw you were on my system this afternoon, and you 
>probably noticed a few changes. After I installed all of 
>those system patches last night, I changed the swap space 
>from my old drive to my new hard drive this afternoon. That 
>seems to have helped performance. (I actually checked on 
>the prices for new RAM for the SPARC 20, and found the 
>prices were outrageous. I doubt we'll be adding memory. I 
>would probably go to a new system first!)
>
>I also found we were having some problems writing to the 
>log files and to the gempak data driectories. I'm not sure 
>why, since they were all group writable directories and all 
>of the directories belonged to the "apps" group that is 
>shared by gempak, mcidas and ldm. Nevertheless, I made sure 
>all of the directories were owned by ldm, and this solved 
>the problem. I think that may have been the reason so many 
>decoders were hanging around and chewing up CPU cycles and 
>memory. The performance has been vastly better since then.
>
>I downloaded the latest patch level for GEMPAK and 
>installed it. I also downloaded and built ldm 5.1.1. I 
>tried throwing the runtime switch and starting it, but the 
>"ldmadmin start" hung. I don't have time this afternoon to 
>figure out why, so I went back to ldm 5.0.8. I'll have to 
>create a new log file and try it again.
>
>If the performance stays this good (loads around 1 or so), 
>I may actually try sending the GINI data across the LDM 
>from the NOAAport system, as I mentioned before. That can 
>wait for another day.
>
>Let me know if you are able to get the compressed GINI 
>files via ADDE.
>
>We're making progress! Thanks for your help.
>
>Tom
>
>
>
>
>On Wed, 09 Aug 2000 00:09:04 -0600 Unidata Support 
><address@hidden> wrote:
>
>> >From: "Thomas L. Mote" <address@hidden>
>> >Organization: University of Georgia
>> >Keywords: 200007172022.e6HKMuT11816 UGA McIDAS-X ADDE NOAAPORT GINI imagery
>> 
>> Tom,
>> 
>> It turns out that I can access your ADDE server through the uncompressed
>> port (500), but not through the compressed one.  This is strange since
>> the entries for both look correct in /etc/services and /etc/inetd.conf.
>> This _will_ have to wait until tomorrow, I fear.
>> 
>> The good news is that I was able to get listings of your GINI imagery
>> from your remote ADDE server!  Now, once we get the compression part
>> figured out, things will be operational.
>> 
>> BTW, as I write this, I note that the LDM is not running on cacimbo.
>> Was this by design, or did it shut down?
>> 
>> Tom
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>
>**********************************************************
>Thomas L. Mote                               address@hidden
>Associate Professor of Geography         ph:  706-542-2906
>University of Georgia                    lab: 706-542-6060
>Athens, GA 30602-2502 USA                fax: 706-542-2388
>