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

Hi Mike,

re: Did you change how you are REQUESTing the SATELLITE feed products in the
last few days?

> Just this morning I changed from DIFAX to SATELLITE because I thought maybe
> that was causing an issue, but this had no effect.

You seemed to have changed from DIFAX to Satellite, not SATELLITE.  I was
under the impression that the feed name was case sensitive, so I would
change Satellite to SATELLITE and restart your LDM to see if that makes
any difference (Steve have made a change that allows feed names to be
specified in lower or mixed case, so this is a shot in the dark).

re:
> Yep, here are the active "request" entries:
> First a Note: I commented out this mesoscale entry just this morning as a
> test, which looks like it reduced the data feed, especially number of
> products. And I see in my directories data stopped seeing data at 16Z,
> which confirms in my mind at least that this type of entry works.
> #request        Satellite       "ABI-L1b-RadM"  idd.unidata.ucar.edu
> 
> [ldm@vulcan etc]$ grep -i ^request ldmd.conf
> request IDS|DDPLUS|HDS  ".*"    idd.unidata.ucar.edu
> request UNIWISC ".*"    idd.unidata.ucar.edu
> request FNEXRAD         ".*"    idd.unidata.ucar.edu
> request FNMOC           ".*"    idd.unidata.ucar.edu
> request CONDUIT   "[05]$" idd.unidata.ucar.edu
> request CONDUIT   "[16]$" idd.unidata.ucar.edu
> request CONDUIT   "[27]$" idd.unidata.ucar.edu
> request CONDUIT   "[38]$" idd.unidata.ucar.edu
> request CONDUIT   "[49]$" idd.unidata.ucar.edu
> request EXP     "cosmicrt"      idd.unidata.ucar.edu
> request EXP     ".*"            mrms-ldmout.ncep.noaa.gov
> request NGRID   ".*"    idd.unidata.ucar.edu
> request Satellite       "ABI-L1b-RadC"  idd.unidata.ucar.edu
> request Satellite       "ABI-L1b-RadF"  idd.unidata.ucar.edu
> request Satellite       "GLM-L2-LFCA"   idd.unidata.ucar.edu
> REQUEST NIMAGE  "GOES"  idd.unidata.ucar.edu
> request NIMAGE  "satz"  iddb.unidata.ucar.edu

Aside from my comment about changing Satellite to SATELLITE, I don't
have anything further to add about these entries here.
re: A quick look at the volume of SATELLITE data that vulcan is reporting
as being received shows that it is not getting everything wanted:
>
> http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?SATELLITE+vulcan.science.sjsu.edu

> Agreed

re: Even though you are not REQUESTing all of the SATELLITE feed, the volume
and peaks/valleys in volume is _heavily_ dominated by the FullDisk images
especially Channel 02 (0.64 um) images.

I want to follow that up with the comment that the second most voluminous
set of SATELLITE products is the CONUS ones, and those are also dominated
by the Channel 02 (0.64 um) ones.

re:
> that could certainly explain a few things.  Which means it shows up more
> in the volume, but not as much in the number of products on a relative
> scale.

Correct.

re:
> But the CONUS imagery is coming in and filing fine, while the
> Fulldisk "RadF" is not.

The volume of NGRID data that vulcan is reporting as being received
is also MUCH less than it should be.

Compare the volume of NGRID being reported by the real-server backend
that is feeding vulcan:

http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NGRID+node2.unidata.ucar.edu

against that being reported on vulcan:

http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NGRID+vulcan.science.sjsu.edu

You are essentially not getting any NGRID data!

re: The next thing that we want to see is the outputs of:
/sbin/ifconfig -a    <- to get the name of your Ethernet interface

> eth2

OK.

re: dmesg | grep <name of your Ethernet interface>

> [ldm@vulcan etc]$ dmesg | grep eth2
> [    3.055124] bnxt_en 0000:19:00.0 eth2: Broadcom BCM57416 NetXtreme-E 
> 10GBase-T Ethernet found at mem 9dc10000, node addr b0:26:28:15:b4:0c
> [    9.232083] bnxt_en 0000:19:00.0 eth2: NIC Link is Up, 1000 Mbps full 
> duplex, Flow control: none
> [    9.232091] bnxt_en 0000:19:00.0 eth2: EEE is not active
> [    9.232096] bnxt_en 0000:19:00.0 eth2: FEC autoneg off encodings: None

I think that this is saying that vulcan as a 10 Gbps Ethernet interface, and 
that
interface is running at 1Gbps.  If this is correct (Mike has left for the day,
so I can't double check with him), then it should either mean that vulcan
is connected to a 1Gbps port on the switch or somehow it dropped from 10Gbps
down to 1Gbps.  Do you know if the latter situation is possible?

Can you send the output of:

/sbin/ifconfig -a

re:
> thanks for any help!

Have there been any network changes in the past several days?  This would
include, but not be limited to:

- vulcan being moved to a different switch
- SJSU adjusting firewall parameters
- etc, etc, etc


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.