[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,

I have not heard back from FNMOC re the feed, so any data that is bursting
through I suspect would not be of value. They are in the midst of network
issues. That is why the data is also not available via ftp or http access.

These are 2 unique issues, hopefully one of them can be worked out so
access to the data resumes.

We have discussed running the LDM on another port (now possible with
LDM 6.4.*) and hopefullly they can clean up their other network issues so
data can be accessed via ftp and http. FNMOC mentioned they had over
20,000 products that were not making it to the ftp server (the other
_internal_ network problem).

The feed is point to point, so I would need to ask FNMOC to add "blue" to
the allow list, but that seems like a moot point as we know where the
problem exists...FNMOC.

I will contact FNMOC again today to see if the status has changed.


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  :
---------------------------------------------------------------------

On Thu, 29 Jun 2006 address@hidden wrote:

>
> Dear Jeff,
>
> Just curious, is there anything that can slow the ingest of ldm grib data
> or a command to resend data? I am still amazed how nogaps is coming in
> several files in a minute (~60 mb worth), so fast such that no files are
> complete. In fact, I don't even see how these partial files can come in
> that quickly given our typical bandwidth. This is definitely different
> than before, in which the files came 1-2 per minute and were complete.
>
> To rule out our thunder machine problem, we would still like to test on
> our blue.msrc.sunysb.edu.
>
> I have a new project with the Navy starting in August, so I'm guessing I
> may need to go right to the source to get the data if problems persist.
>
> Thanks,
>
> Brian
>
> On Sun, 25 Jun 2006 address@hidden wrote:
>
> >
> > Dear Jeff,
> >
> > Thanks for the heads up. The data since the 23rd has been coming in again,
> > but many are partial files. Several files are being sent each minute for
> > some reason, so I do wonder about overload on our machine, especially if
> > you are seeing complete files. Therefore, we would like to test another
> > ldm machine that we have setup for Conduit ingest, blue.msrc.sunysb.edu
> > (129.49.64.73), to see if it does better. Can you please give permission
> > to blue to ingest nogaps?
> >
> > Thanks again,
> >
> > Brian
> >
> > On Fri, 23 Jun 2006, Jeff Weber wrote:
> >
> > > 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
> > > > >
> > > >
> > >
> >
>