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

[Staging #BXC-728734]: Re: 20120210: CONDUIT & RUC/RAP Transition (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [Staging #BXC-728734]: Re: 20120210: CONDUIT & RUC/RAP Transition (cont.)
  • Date: Fri, 23 Mar 2012 14:21:32 -0600
Hi Becky,

re:
> I agree with Tom's explanation. Tom Y, we should be up to only new data
> now so if you see it continue let us know.

Yup, Tom P gave me a call (nice!) to explain what happened "in person".
I have been eyeballing the CONDUIT volume plots, and it looks like the
volumes have returned to normal.

re:
> But this is a good thing for us to keep in mind. We let the data build
> up so we can populate the WOC systems but in future cases like this we
> should disable the CONDUIT feed since you all work only in a real-time
> mode and as we see re-population is a bad thing.

My initial reaction was exactly like yours: it would be better to dump
the old runs in favor of the new.  Now that I have had some time to
ponder this further, I am uncertain of what our users would want.
In a situation like today's, I still think that it is a no-brainer to
not send backlogged data mainly since the data had already been
delivered by other toplevel machines.  In the case where none of the
data had been sent, I wonder what the end-users would prefer:

- dump the data in favor of new

- get the new data then the old data

- get all of the data in the temporal sequence that it should
  have been in

One thing to keep in mind is that it is most likely that no all of the
old data actually made it out of the LDM queue on ncep-ldm0.  The reason
I say this is that the queue is not nearly big enough to handle all
of the data that should have gotten dumped to it since the rate of
insertion of products into the queue is not throttled (or is it?).

Anyway, all's well that ends well :-)

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: BXC-728734
Department: Support CONDUIT
Priority: Normal
Status: Closed