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

19990406: LDM Gempak Decoder Problem

Brian,
I logged into your system and looked at dcnldn. It looks like the ldm 
is killing off the dcnldn before the decoder flushes its buffer out
to the file- eg the Terminated messages in the log file. I added a -t 30
flag to your pqact.conf entry so that the decoder would close itself
down after 30 seconds without data so that the file could be
properly closed.

McIDAS has to restart the decoder every time- which is why that is
not a problem. Gempak saves the overhead of having to restart the decoder
if data comes in regularly- but normally closes down after 10 minutes
of inactivity. Its possible that the added data is making the LDM kill off
children to handle the flood of data on a restart- eg getting  backlogged
data all at once when the queue is remade. I may need to make dcnldn catch 
the termination from the LDM differently if this is a Linux problem.

In general, a P200 with 64MB of ram should be adequate for your LDM server.
Other than that, it would depend upon how much other data processing you 
intend, or file service to other machines that the server is forced
to handle.

Steve Chiswell
Unidata User Support


>From: Bryan Rockwood <address@hidden>
>Organization: .
>Keywords: 199904070335.VAA27202

>Unidata,
>
>I am having a small problem with the dcnldn decoder that I was hoping you
>could take a look at.  I have all file permissions set correctly and am
>using the correct syntax in the pqact.conf file.  The problem is that the
>encoder in question does no do any output to the file.  At each hour, it
>will create the file for that hour, but not put any data into it.  It was
>working fine till about noon today and went to pot.  The MCIDAS decoders
>decode the nldn data fine.  I even tried to move the dcnldn to the top of
>the pqact file to see if that helped, but it did not.  It did ingest about
>10 minutes worth of data, but then crapped out as well.  I had the server
>crash over the weekend (a important lesson that teaches me the importance
>of a server backup :)) and I had to salvage what I could as far as config 
>files. Fearing that a corrupt config was the problem, I rebuilt the pqact
>from scratch from examples downloaded from Unidata's website.  Still will
>not work.  We have certain factions that are McIDAS and some that are Garp
>and would like to keep both running together.
>
>Since I have your attention, there are some general info questions that I
>would like to ask since you guys have had so much more experience at this.
>Since the server crashed, I decided to start getting much more data than
>we were before.  That includes the grib and text data on top of the McIDAS
>stuff.  In your experience, am I biting off more then I can chew?  The
>base system is a P200 and memory is 64Meg.  The pipeline is a split T1.
>HD space is not an issue.  I know that there are other factors to consider
>here, but a general opinion on this would be greatly appreciated.
>
>Finally, since you guys are poking around in the system (hopefully), could
>you take a look in the ldmd.log file and just browse a bit to see if there
>is something glaring that I missed.  As always, I would greatly appreciate
>it.
>
>The gempak and mcidas directories are members of the same group as ldm and
>have full read write stuff enabled.
>
>********************
>Bryan Rockwood:  address@hidden
>System Administrator, Creighton University, Atmospheric Sciences
>"I drank what?!" -- Socrates
>********************
>
>
>
>
>
>