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.
Hi again Daryl, Another comment: I took a look at the real-time stats being reported by both metfs1.agron.iastate.edu and metfs2.agron.iastate.edu, and it seems that the high latencies are being reported for the highest volume feeds being REQUESTed, CONDUIT and NGRID. Here is a listing of the volumes being reported by metfs1: Data Volume Summary for metfs1.agron.iastate.edu Maximum hourly volume 32333.782 M bytes/hour Average hourly volume 17422.871 M bytes/hour Average products per hour 306925 prods/hour Feed Average Maximum Products (M byte/hour) (M byte/hour) number/hour NGRID 9261.417 [ 53.157%] 14084.641 58195.975 CONDUIT 3407.846 [ 19.560%] 12784.612 49240.600 NEXRAD3 2440.436 [ 14.007%] 2914.372 112083.575 HDS 1204.240 [ 6.912%] 1639.485 39299.700 EXP 525.464 [ 3.016%] 1457.611 4047.350 FSL2 200.574 [ 1.151%] 650.261 48.800 FNEXRAD 117.786 [ 0.676%] 139.598 100.650 NIMAGE 84.579 [ 0.485%] 144.219 109.050 UNIWISC 68.057 [ 0.391%] 136.957 43.575 IDS|DDPLUS 65.436 [ 0.376%] 79.650 43682.025 NEXRAD2 46.742 [ 0.268%] 114.076 17.250 LIGHTNING 0.295 [ 0.002%] 0.682 56.000 The existence of high latencies for high volume feeds and low latencies for low volume feeds is a "classic" feature of volume-related bandwidth limiting on a per-connection basis. The only ways that we have found to workaround this kind of imposed bandwidth limiting are: - work with the campus network group to see if the limiting has been imposed locally by mistake and can be altered - split the feed REQUEST(s) into multiple, disjoint REQUESTs This is easily done for CONDUIT as each product has a monotonically increasing sequence number, but not so easily done for NGRID. The one thing you can do immediately is isolate the REQUEST(s) for the highest volume feeds (i.e., don't REQUEST any other feed in the same REQUEST). The next step would be to start splitting the feed REQUEST(s) and then run for awhile to see the effect on the reported latencies. I would guess that this latency issue is fairly new. If this is the case, I would suspect that the network folks at IASTATE have imposed some bandwidth controls either intentionally or unintentionally. We have seen several instances where a campus starts using software from Palo Alto Networks, and they have unintentionally started limiting legitimate network traffic. 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: UQG-528842 Department: Support IDD 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.