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

John,

> So going from .0175 to .03 seconds between packets in a TCP conversation is 
> enough to cause the latency we are seeing?

According to 
<http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume?uni14.unidata.ucar.edu>,
 about 6e9 bytes arrive every hour on the NIMAGE feed. From that, the rate of 
packet arrival can be approximated:
    (3600 seconds)/(6e9 bytes)(3000 bytes/packet) = 0.0018 seconds/packet

If the time *between* packets is 0.03 seconds, then the network is too slow to 
keep up.

> If you think that packet to packet (time between packets in a 388 
> conversation) time has nothing to do with the latency we are seeing (and 
> wouldn't necessarily be seen while we are seeing the LDM latency), please 
> explain the physics to me because I'm seriously lost.  I cannot for the life 
> of me understand how this latency could be occurring without me seeing the 
> packet to packet times increase dramatically.

> I'm aware that networks can drop packets in a bad connection (where I'll see 
> Retransmits and Duplicates), block packets altogether (where there would be 
> RST ACKs most likely), or sequester/buffer/queue packets.   The third I have 
> not seen in a packet capture and could only guess what it looks like (i.e. 
> many Retransmits with eventual new SYN requests as seen in a web server's 
> denial of service instances).

If a packet-shaping system were discarding packets, then you wouldn't see any 
retransmissions because the TCP layers constantly recompute the 
retransmission-timeout (RTO) parameter based on the round-trip time (RTT). They 
do this to avoid retransmissions. A packet-shaper would, effectively, increase 
RTT and, hence, the RTO used by the TCP layer.

> The packet capture you sent me had no traffic originating from mammatus.  Did 
> you filter that out or was that a delay of 3 seconds?  It looks filtered out.

It was filtered out. What I sent only contained packets from us to you for the 
NIMAGE feed.

Regards,
Steve Emmerson

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.