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

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

Hi Mike,

re:
> Thanks for your comments. We've been evacuated for the past two hours due
> to a leak...joy.  Still out of my office,

When it rains, it pours!

re:
> but I looked at the cpu plots and
> can confirm that those are python routines that plot GOES data.  I still
> need to determine exactly why they were running when there was no new
> data, but indications are they were cycling through old products.  Probably
> a weakness in my code.

OK.

re:
> Anyway, we'll keep plugging away here.  I think I've convinced our network
> folks that some kind of shaping is at play here.

If you have convinced your network folks that something new is going on,
you have been way more successful than other sites we have worked with
in similar situations!

One other test that could be run:

- change the REQUEST for the SATELLITE data to our old IDD relay cluster,
  iddc.unidata.ucar.edu

  Why?  The real-server backend machines in the iddc.unidata.ucar.edu
  cluster are setup for non-jumbo frames (MTU of 1500).  The real-server
  backends of the idd.unidata.ucar.edu and iddb.unidata.ucar.edu
  clusters are all setup for jumbo frames (MTU of 9000).  Daryl Herzmann
  of Iowa State reported a problem with running an LDM on a machine
  in one of their datacenters that was found to be caused by routers
  not keeping up with the overhead of jumbo frames (not phrased exactly
  correctly, but that's the idea).  At the same time, a machine running
  the LDM in another datacenter did not have any problems for essentially
  the same feeds.  Weird, but true.

  If switching to feed SATELLITE from iddc.unidata.ucar.edu doesn't
  result in products being received, you can even try REQUESTing
  directly from one of the real-server backend machines directly.
  I recommend uni24.unidata.ucar.edu

Another thing to check on is to make sure that the Ethernet interface
on vulcan is still running at 1 Gbps no duplex.

Another question that we mentioned in one of our exchanges that I
don't remember seeing an answer to is what is the physical connection
between vulcan and the Internet.  What I am really asking is why the
machine is going through a NAT, and what hardware is doing the NAT.

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.