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

[LDM #AET-991057]: LDM 6.4.4: upstream connection closed for unknown reason

> 
> No, not yet, but just now I ftp'ed over to the data archive on motherlode and 
> see that the decoded GFS is it's normal size. So I think everything came in.  
> I know that the machine in New Mexico received everything fine yesterday 
> while the one here had the holes.  Jst for the heck of it (even though I know 
> a ping to idd.unidata.ucar.edu looks much worse than to bigbird) I am going 
> to point at idd.unidata.ucar.edu for the 18Z run.
> 
>

Robert,

The .status file in the CONDUIT data stream provides the inventory of what 
products should
be expected. I provide a comparison between the data received on motherlode and 
the products
filed onto our disk on the web (not for gfs .5 degree but for all other data 
sets) at:

http://motherlode.ucar.edu/cgi-bin/ldm/conduit_reception.csh

Eachseparate file is available for comparison.

If you are missing data in your output file, and your latencies do not exceed 
that
of your upstream's ability to buffer the data in its queue such that you should 
have received the
data locally (which can be verified though logging notifyme to your machine), 
then it is possible 
for the data to be overwritten in the local queue before pqact sends it to the 
decoder
if your disk IO is slow and/or your pqact process is overburdened (you can 
split your
pqact processing with more pqact processes too). Switching the pqact process
to debug mode to show the "delay" messages would show if it is taking too long
to get data out of the local queue (run "kill -USR2" for the pqact process id to
cycle to debug mode....but don't leave like that because all that logging
will be a load in itself!).

Steve Chiswell
Unidata User Support






Ticket Details
===================
Ticket ID: AET-991057
Department: Support LDM
Priority: High
Status: Open