[LDM #AFT-567406]: GOES-17 data filing question

Hi Mike,

re:
> I would like to keep this on the burner and try to figure out what's going
> on.

Just so you know, we have not relegated this to the back burner.  If you
get a reply from our inquiry tracking system that indicates that the
status is closed, please rest assured that this does not indicate that
we think that the problem is solved.  Sending a new email that contains
the Ticket ID automatically opens the ticket, and we are sent notifications
about the receipt of a new reply.

re:
> The main thing that does not add up to me is that the latency on the
> Satellite data is not the bad:
> 
> http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?SATELLITE+vulcan.science.sjsu.edu

I agree.  Seeing low latencies without actually receiving products should
mean that there are relevant messages in the recipient's LDM log file
that should be read for content.  Your comment that there were no relevant
messages in your LDM log file is a puzzler!

By the way, if you look at the latency plot for SATELLITE right now, you will
see that it climbed rapidly towards 1 hour.  This is the effect that we
would expect to see in situations where not all of the products in a feed
are being received.

Would it be possible for us to logon to vulcan so we could poke around?
At a minimum, we would need access as 'ldm', but there is a chance that
we would need 'root' also.  If the answer is yes, you can call me to 
let me know the login information, my work number is 303.497.8642.
(Remember that I already have the credentials to login to the SJSU VPN
server.)

re:
> And yet, I'm not getting Full Disk imagery, while I am getting all the
> CONUS.

Forgive me for saying this, but I find this hard to believe given the
real-time stats SATELLITE volume plots from vulcan.  Of course, I
could be completely wrong, but...

re:
> And FullDISK is not completely blocked, an image does come in once
> in a while.  So I can imagine some "feature/rule/condition" where larger
> file sizes are "restricted/blocked" somehow even if not intentional.  Now
> this "blockage" could be on vulcan, on our network, with the NATing or this
> could be a red herring.

I do not understand what could be the cause of what you are seeing.
However, another site, UW/AOS, has a similar strange experience with
receipt of SATELLITE and NIMAGE data.  In their case, their "accumulator"
machine to their relay cluster can not get SATELLITE or NIMAGE with
small latencies when REQUESTing directly from us.  They moved
their SATELLITE and NIMAGE REQUESTs to another, less loaded machine,
and that machine does not show high latencies in getting either feed.
They then REQUEST both SATELLITE and NIMAGE from the second machine
on their "accumulator", and there are no latencies see there.  Given
this experience, I would propose that you try the same sort of setup
if you have a lightly/unloaded machine on which you can run an LDM
and REQUEST the SATELLITE, NIMAGE and possibly NGRID feeds, and
then REQUEST those feeds from vulcan.  Would this be possible?

re:
> There could be two separate problems here also.  I certainly do have  a
> latency problem on NGRID and CONDUIT that I need to resolve, but I can't
> tell if that has any connection to my Satellite feed issues.  My CONDUIT
> and NGRID data does actually come in, albeit a bit late.

Your NGRID data is _not_ coming in fully.  Compare the volume plot for
the NGRID feed from vulcan and compare it against any of the real-server
backends of the idd.unidata.ucar.edu cluster:

node0.unidata.ucar.edu
 ...
node7.unidata.ucar.edu

re:
> Could you and team ponder the rtstats for vulcan to shed some light or
> recommend a troubleshooting strategy?

I will be getting Steve and Mike together today to discuss this situation.

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: AFT-567406
Department: Support LDM
Priority: Normal
Status: Open
===================
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.