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

Hi Mike,

re:
> could you let me know your VPN username. (It sounds like that still
> works...could you check?) I can check quick on this end how to get
> you access to vulcan.

I use 'jsmith' as this is what Sen gave me some time ago.

I just tested connecting to the SJSU VPN server and then logging onto
titan (as Sen), and it still works.  I am not longer able to become
'ldm' on titan as it looks like Sen lost his ability to 'sudo su - ldm'.

re:
> As a test, I added these entries on my other machines.
> 
> on Charney:
> request SATELLITE       "ABI-L1b-RadC"  vulcan.science.sjsu.edu
> request SATELLITE       "ABI-L1b-RadF"  vulcan.science.sjsu.edu
> 
> on titan (older version of LDM, so I think it needs "DIFAX"):
> request DIFAX   "ABI-L1b-RadC"  idd.unidata.ucar.edu
> request DIFAX   "ABI-L1b-RadF"  idd.unidata.ucar.edu

OK.  I don't think that this will solve anything based on my current
conceptualization of what may be going on.  Here is what I am thinking:

It seems that systems that have problems REQUESTing the SATELLITE
and/or NIMAGE feeds are ones that are also REQUESTing lots of other
feeds.  This results in there being a mixture of large and small
product in the LDM queue, and a number of small products in the
queue will need to be "aged off" in order to make room for newly
received large products like those in the SATELLITE and to a
lesser degree NIMAGE feeds.

The fact that doesn't fit this conceptualization is the reality at
UW/AOS - REQUESTing the SATELLITE and NIMAGE feeds on a lightly
loaded machine (read lightly loaded as meaning not a lot of feeds
are being REQUESTed) machine results in very low latencies (this
fits the idea) but then the low latencies continue when those 
feeds are REQUESTed by the accumulator for the UW/AOS relay
cluster.

Mike and I talked this over at some length a while ago, and he
made a comment/musing that perhaps some network tuning is called
for on vulcan.  What does this mean in practice, you may ask?
Here are some network tuning parameters that we add to the
/etc/sysctl.conf file on all of our machines here in Unidata:

#
# TCP tuning
#
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.ipv4.tcp_wmem = 4096 2000000 16777216
net.ipv4.tcp_rmem = 4096 524288 16777216
net.ipv4.tcp_adv_win_scale = 7
net.ipv4.tcp_moderate_rcvbuf = 1

re:
> I have to go to a lunch meeting.  back a bit later.
> thanks,

OK, and no worries.

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.