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.
Don & Chris, > For each radar XXXX: > > request EXP ".XXXX" IP > > The products don't exist...yet. When RPG Build 12 is fielded late Aug to > late Sept, the EXP product will exist. I think that's the cause of the slow response. On the newly-promoted aggregation system, each downstream LDM process will search though the product-queue for the most-recently received matching data-product. The LDM queue is implemented as a unidirectional skip-list (from oldest data-product to most-recent) so searching for the most-recently received data-product is an O(log N) operation. On average, each NEXRAD2-requesting downstream LDM will find a matching product after 77 such searches. Because there are no EXP data-products in the queue, however, each EXP-requesting downstream LDM will search the entire queue before giving up, which is an O(N log N) operation. I think you have 154 processes searching the entire product-queue for products that don't exist and that this is eating-up the CPU-s and delaying the response. I tested that hypothesis here and the restart time went from 30 seconds at the most to about three minutes. The LDM wasn't relaying any data, so that might account for its response being less than 10 minutes. I suggest that you remove the requests for EXP data until such data-products become available. > Chris > -- > > Chris Calvert > Software Engineer > National Weather Service > WSR-88D Radar Operations Center > 1313 Halley Circle, Norman, OK 73069 > (405) 573-3323 Regards, Steve Emmerson Ticket Details =================== Ticket ID: QKY-452311 Department: Level II Priority: Normal Status: Closed