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, re: > My local monitoring has been showing sporadic NEXRAD2 IDD latencies > on the order of 600 seconds since Friday (9 Sept). You can see these here: > > https://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?NEXRAD2+node0.unidata.ucar.edu > > Are known troubles afoot? We have not seen any notifications related to the NEXRAD2 feed from NOAA, and the flows out of our IDD relay clusters appears to be ioeratibg normall. re: I was feeding from idd.unidata, but have switched to iddb.unidata as it does not > appear to have these issues. Given the NEXRAD2 latency plots for randomly chosen real-servers backends of the Iddb.unidata.ucar.edu cluster, which is housed in the main machine room at the NCAR Mesa Lab, I would have said that the high latencies your monitoring is showing would be worse, not better than nodes in the idd.unidata.ucar.edu cluster, which is housed in the NCAR Wyoming Supercomputer Center in Cheyenne, WY. It could be that the products from stations whose high latencies were/are triggering your alarms are not being inserted in the LDM queues on the IDDB cluster backends, so your monitoring would not show them as being abnormally high since they are never received. I just checked the indicated NEXRAD2 latencies on the three accumulators (the machines that make the REQUEST to upstreams) of our clusters, and one is showing very high latencies for the NEXRAD2 feed while the other two are not. Exactly why this is happening is not known at the moment, but we will investigate. Given the redundant feed REQUESTs that all of the backends of our clusters have, it is most likely that the high latencies being seen are coming from this one accumulator (oliver.unidata.ucar.edu), and those products may well be "second trip" products, which is how we refer to products that are received more than once but late enough that they are not ignored by the LDM duplicate product detection and rejection mechanism. Again, further investigations will be made... 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: AYS-505040 Department: Support IDD Priority: Normal Status: Open =================== 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.