20051006: 20051005: 20051003: pqact template for GFS conduit data

John,

The problem you are describing sounds like your LDM relay is falling behind, and
independent of any GEMPAK configuration.

As an aside, you should be requesting data from idd.unidata.ucar.edu now
since thelma.ucar.edu no longer exists, and is just a name alias. The 
idd.unidata.ucar.edu is a cluster of hosts to provide you with the most
reliability. Note that this is not related to your data stream problems.

I am running a notifyme command to both your LDM machines to watch the CONDUIT
feed arrive there. 

Your old machine "newpsn" which is being fed from "thelma" is receiving the
full gfs #003 per your description. The machine "psnldm" is feeding from 
"newpsn".
The likely situation is that:

The "newpsn" machine is falling way behing in receiving the CONDUIT feed.
At this moment, it is receiving the F024 fields, and they are over 30 minutes
behind. Once this machine falls more than 1 hour behind realtime in receiving 
the data,
your downstream machine "psnldm" will start missing data, since the default LDM 
configuration 
is to ask for data up to 1 hour old, and on receipt of a product older than 
that, it will ask to 
skip ahead in time so as to catch up.....but since your upstream "newpsn" is 
the one
that is falling behind, "psnldm" is unable to catch up in time.

If your machines were sending statistics in, using the rtstats program 
invocation from ldmd.conf,
we would have a record of latency for your products and verify that the 1 hour 
latency is occuring.
I will use notifyme as a substitute for the time being and watch as the F084+ 
times
arrive, given you said that you see problems on your downstream in that time 
between F084
and F180.

The likely solution is to examine your LDM performance on "newpsn", the size of 
your queue
and its memory. If your plans are to replace that with the "psnldm", the best 
case would
be to have enough memory to hold your entire queue size, and your queue should 
be
large enough to hold at least 1 hours worth of data. The newer psnldm seems to
be keeping up with "newpsn" in terms of feed volume, so we should see data 
drops as the
upstream falls over 1 hour behind, and prpbably RECLASS messages in your 
ldmd.log file.

Steve Chiswell
Unidata User Support

Steve Chiswell
Unidata User Support




>From: "John Hobbie" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200510062146.j96LkLG7002275

>Steve --
>
>More info on this problem.  I hope this might give some insight into what is h
> appening.
>
>Today, I sat with GARP running on both machines watching GFS003 come in -- the
>  12Z data set.  The data showed up similtaneously on both machines up through
>  84 hours.  The older machine, "newpsn", which is fed by thelma, kept on fill
> ing out GFS003 past 84 hours through 180 hours.  The machine with the latest 
> GEMPAK/LDM versions, "psnldm" which is fed by "newpsn", only got 9208 fields,
>  while the "newpsn" machine captured 20026 fields.
>
>The other problem is that number of fields logged in GFS003 on "psnldm" varies
>  from run to run, but hovers around 9500 fields.   There do not appear to be 
> any missing fields within the data that is captured (skimming the results of 
> GDINFO.)  That is, even though psnldm is not capturing the entire length of t
> he set (180 hours), it captures every field until it stops about half way thr
> ough the data (about 84-90 hours).
>
>I don't know what is filling up -- number of files open or memory overflow, et
> c. -- but the same general problem arises whether day or night or product run
>  (18Z or 06Z).
>
>
>Do you have any ideas what these symptoms are indicating?  
>
>
>Hobbie 
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.