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.
Harry, If you look at your rtstats(1) results, Freshair is seeing high latencies in the WMO and UNIWISC feeds from unidata2.ssec.wisc.edu but not in the CONDUIT feed from Idd.unidata.ucar.edu. Tom thinks that this is related to a previous problem you had: Tom says "Hi" and asks you to remember the tuning that you did on the kernel on Freshair that got rid of the high latencies you were seeing on all feeds except CONDUIT a little over a month ago. The reason he makes this comment is that yor're now again seeing those high latencies. Wasn't this related to some sort of "fairness" algorithm in the kernel? It seems to Tom that you're running into the exact same thing again. Plus, it's Friday! :-) I don't know about the above problem. I note, however, that the product-queue on Freshair is limited by the amount of space available for in its data portion (it has more than enough data-product slots). This means that as space is needed, the oldest data-products will be deleted to make room for more. Because the data-products from unidata2.ssec.wisc.edu are arriving so late, I suspect they're being preferentially removed to make room for other data-products. My suggestion, therefore, is for you to split-up your requests for data from unidata2.ssec.wisc.edu the way the request for CONDUIT data from idd.unidata.ucar.edu is split-up. Apparently, on Freshair, throughput is greater for more TCP connections than for fewer. I also suggest that you investigate Tom's contention. Regards, Steve Emmerson Ticket Details =================== Ticket ID: ZRE-293921 Department: Support LDM Priority: Normal Status: Closed