Re: No WSI feed from wsihcsn.unidata.ucar.edu to iita at 99082610 (fwd)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Thu, 26 Aug 1999 17:48:45 -0600 (MDT)
From: Peter Neilley <address@hidden>
To: address@hidden, address@hidden
    address@hidden, address@hidden
Subject: Re: No WSI feed from wsihcsn.unidata.ucar.edu to iita at 99082610

All:

  I'd like to summarize/paraphrase Robb's note and other facts
  to help understand where we are now and what we need to 
  do to correct this issue:
  
  - Large WSI data latencies between wsihcsn and iita started appearing last 
    week once the iita (Linux box)  was upgraded to LDM 5.0.8.  At first, there 
    was some speculation that these latencies were associated with work/changes
    in the network at FL4, but that theory has been discounted by Mike S. now 
    that those changes are fixed/completed.
    
  - Before last week, and ever since the new iita machine was installed last
    spring, latencies between wsihcsn and iita were trivial.
           
  - Have there been any substantial changes in the volume of data feeding iita?
    There were some reports on the ldm-users email list that NOAAPORT NIDS
    products were getting through onto the IDD.  Chiz fixed a regular
    expression pattern on thelma, but perhaps a similar fix needs to get 
    in place on iita?  Are there loads of NOAAPORT NIDS products arriving
    at iita directly from the UCAR NOAAPORT that are overwhelming iita?
    If this is not an issue, I know of no other changes in the datafeeds
    or the load on iita that bear on this problem. 
    
  - Robb increased the pq size on iita, and cleaned up some rouge ldm
    processes on iita.  This did not improve the situation.
    
  - Robb reported that ldmping from wsihcsn was refused by iita.  This was
    corrected by "allow"ing wsihcsn at iita, but no improvement in 
    throughput.
    
  - Robb reports problem with rpcinfo.  We talked with our systems folks
    (ie Tres) and we don't know how to interpret this error, nor what
    to do about it.    
   
  - Robb suggests the problem might be with the firewall since sites outside
    the firewall (like wsihcsn) are not seeing latencies:  Questions:
    
      a)  Why are so many sites getting data from wsihcsn?  Who is
          shemp and torrent?  Are they both FL4 sites?  If so, one should
          feed the other.  Why is ldm.comet getting data from wsihcsn
          rather than iita?  Is that just a short term solution to get
          timely data to comet until this problem is solved? 
          
      b)  Are sites that are getting the data timely running v5.0.8?  Are
          any LINUX boxes?       
    
    
Have I summarized correctly?  Where do we go from here?          
             

Peter Neilley, NCAR/RAP
address@hidden
303-497-8446