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

[LDM #GUQ-669331]: Both Radar and Satellite feeds stopped downloading abruptly

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [LDM #GUQ-669331]: Both Radar and Satellite feeds stopped downloading abruptly
  • Date: Fri, 27 Sep 2019 10:52:16 -0600
Hi John,

I see that you are now using the em2 Ethernet interface on rime, and
you reverted the feed REQUESTs to point at our top level IDD relay
clusters:

ldm@rime:~$ grep -i ^request etc/ldmd.conf
REQUEST NIMAGE  ".*"    idd.unidata.ucar.edu
REQUEST NGRID   ".*"    idd.unidata.ucar.edu
REQUEST IDS|DDPLUS  ".*"    idd.unidata.ucar.edu
REQUEST NOTHER  ".*"    iddb.unidata.ucar.edu
REQUEST NEXRAD3 ".*"    iddb.unidata.ucar.edu

I further noted that after the change, the latencies for both the 
IDS|DDPLUS and NEXRAD3 feeds have fallen to near-zero values while
the latencies for the other feeds, NGRID, NIMAGE and NOTHER, remain
unacceptably high.

So, the question was/is why the IDS|DDPLUS and NEXRAD3 feeds have low
latencies while the other feeds have high latencies?

This question prompted me to look at 'ifconfig' output for em2 and,
after verifying that the machine had been rebooted, how the Ethernet
interface is setup:

ldm@rime:~$ /sbin/ifconfig em2
em2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 129.118.105.28  netmask 255.255.255.0  broadcast 129.118.105.255
        ether d0:94:66:63:ea:7a  txqueuelen 1000  (Ethernet)
        RX packets 22677254  bytes 33832574418 (31.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11053388  bytes 851253987 (811.8 MiB)
        TX errors 2  dropped 0 overruns 0  carrier 2  collisions 2
        device memory 0x91a00000-91afffff  

ldm@rime:~$ dmesg | less
 ...
[  837.254134] igb 0000:01:00.1 em2: igb: em2 NIC Link is Up 100 Mbps Full 
Duplex, Flow Control: None

The 'dmesg' listing shows progress for the em2 Ethernet interface (e.g., it
is now running full duplex), but it still raises the question of why it is 
running
at 100 Mbps (we are under the assumption that it should be a Gbps interface)?

My overall comments now are:

- the feeds with high latencies are composed of "larger" products while 
IDS|DDPLUS
  and NEXRAD3 are composed of "smaller" products - IDS|DDPLUS products are
  very small, and NEXRAD3 products are small to medium sized

  This "feels" like a big clue as to what is going on.

- we think that IF your em2 interface can run at Gbps speeds, and IF the
  switch port that rime is connected to supports Gbps speeds, an effort
  _must_ be made to make em2 run at Gpbs

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: GUQ-669331
Department: Support LDM
Priority: Normal
Status: Closed
===================
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.