[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20000809: 20000808: quick update before going to bed
- Subject: 20000809: 20000808: quick update before going to bed
- Date: Wed, 09 Aug 2000 16:23:26 -0600
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
>