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

Re: New Staff Reply - [Datastream !GFZ-680741]: missing nogaps fields (fwd)

Hi Brian,

Yes, we saw the problem around 12Z on the 19th.

We have contacted FNMOC, and the issue is at their end.

This feed may go away, the DoD has closed access to port 388.

FNMOC is trying to get the data feed opened up again, but they are at the
whim of the DoD, so no timeline has been given, and no assurance it ever
will be.

I currently have a message in to FNMOC to see if the data will be
available via ftp or http, and will keep you posted.

Apologies for any inconvenience,


Jeff
---------------------------------------------------------------------
Jeff Weber                                    address@hidden        :
Unidata Program Center                        PH:303-497-8676        :
University Corp for Atmospheric Research      3300 Mitchell Ln       :
http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000  :
---------------------------------------------------------------------

On Fri, 23 Jun 2006 address@hidden wrote:

>
> Dear Jeff,
>
> I have been out of town for most of the week, but thanks for resending,
> since I did not see the first response.
>
> Since 6/19, the nogaps has not even been coming in for us using our same
> request line to usgodae3.fnmoc.navy.mil. Although our SUN
> machine is fairly busy, I have not seen a dropped grid/data problem
> before. For example, all other grib data (including special CMC and MADIS
> requests) come in great.
>
> Here is what worked for us a few weeks ago:
>
> NOGAPS  ^.*0058_0240_(...)00F0RL(..........)_.*
>         FILE    data/nogaps/\2_\1_nogaps.grb
>
> Yes, we are using the default 400 Mb queue. Unfortunately, after
> switching to solaris 5.9 last year (with Sunscreen), I can not get a
> ldmd.log file to be created after following the instructions. I was
> hoping to avoid this issue for now, since my new dual processor SUN
> just arrived last week, and in July we will be switching to that machine
> for ldm. Meanwhile, the nogaps data has been useful for a student thesis.
>
> Thanks again for the time.
>
> Brian
>
>
> > --
> >
> > Did you get the response listed below?
> >
> >
> > Cheers,
> >
> > Jeff
> > ---------------------------------------------------------------------
> > Jeff Weber                                    address@hidden        :
> > Unidata Program Center                        PH:303-497-8676        :
> > University Corp for Atmospheric Research      3300 Mitchell Ln       :
> > http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000  :
> > ---------------------------------------------------------------------
> >
> > ---------- Forwarded message ----------
> > Date: Tue, 20 Jun 2006 08:25:58 -0600
> > From: Tom Yoksas <address@hidden>
> > To: address@hidden
> > Subject: New Staff Reply - [Datastream !GFZ-680741]: missing nogaps fields
> >
> > New Staff Reply: missing nogaps fields
> >
> > Hi Brian,
> >
> > I apologize for not getting back to you before now...
> >
> > re:
> > > We request nogaps gribs via ldm from usgodae3.fnmoc.navy.mil, and for the
> > > past week we have been noticing some missing fields. For example, last
> > > night the 2006061400 nogaps is missing the PRMSL (slp) field at f00, f12,
> > > and f36. We have not changed anything on our end, so I wonder if you can
> > > please check your nogaps file, or contact fnmoc to see if they have had
> > > some issues.
> >
> > I notice that you are receiving alot of data on the machine that is
> > requesting FNMOC data:
> >
> > thunder.msrc.sunysb.edu
> > http://www.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume?thunder.msrc.sunysb.edu
> >
> > It is possible that you are not processing the data out of your LDM
> > queue fast enough to ensure that data in the queue does not get overwritten
> > by new data being received during peak ingest periods.  In order to 
> > determine
> > if you are losing data out of the LDM queue, please check the following:
> >
> > - the size of your LDM queue.  Your peak ingest rate is just about 2GB/hour.
> >   If your queue is undersized (many sites never increase their queue size
> >   above the 400 MB default), you can easily lose data (not process, that is)
> >   that you have successfully received
> >
> > - you can get more information from the 'pqact' invocation(s) that are 
> > processing
> >   data out of your LDM queue by putting it(them) into verbose logging mode
> >   by sending the process ID a 'kill -USR2' signal.  The first 'kill -USR2'
> >   puts 'pqact' into verbose logging mode; the second puts it into debug
> >   logging mode; the third returns the process to normal (notice) logging
> >   mode.  Put the process(es) into debug mode when the FNMOC data is being
> >   received and see how long it is taking to process the data out of the
> >   queue.
> >
> >   NOTE: do not forget to leave the debug logging mode!  This mode will
> >   generate LOTS of output in your ~ldm/logs/ldmd.log file!!
> >
> > - if you are trying to process all of the data out of your LDM queue
> >   using a single 'pqact' process, then I can all but guarantee that
> >   this is the cause of your data loss.  One instance of 'pqact' has
> >   little chance of processing 2 GB/hour of data
> >
> > As far as our checking our receipt of the FNMOC data, please alert us
> > to the next instance where you see data loss (after checking the things
> > I listed above), and we will see if we missed data.  We can not go back
> > to the 14th to check since we don't keep the data around for that long.
> >
> > > Thanks for your time.
> >
> > Again, I apologize for not being able to get back to you on your inquiry
> > before now.
> >
> >
> > Cheers,
> >
> > Tom
> > ****************************************************************************
> > Unidata User Support                                    UCAR Unidata Program
> > (303) 497-8642                                                 P.O. Box 3000
> > address@hidden                                   Boulder, CO 80307
> > ----------------------------------------------------------------------------
> > Unidata HomePage                       http://www.unidata.ucar.edu
> > ****************************************************************************
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: GFZ-680741
> > Department: Support IDD
> > Priority: High
> > Status: Closed
> > Link: 
> > http://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=1086
> >
>