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.
Art, > Well... based on a sample of 24 hours, it looks like your hypothesis is > correct, or at least the solution works. I've not seen any latency spikes > since I changed the "offset" to 2000 seconds. Something still puzzles me > though... I don't think the reception delay on iddrs3, i.e. the reach-back > into the idd.cise-nsf.gov queue, could have been far enough to exactly > follow the course of events you outlined above since the true latencies > were running below 200 seconds in general with peaks between 1000-1500 > seconds. Because the LDM connection to Cise-Nsf is in alternate mode, it's unlikely that data products from it would make it into the queue due to duplicate product rejection. Consequently, the latencies you see are primarily due to the primary mode connection. It isn't until a mode-switch occurs that the data-products from Cise-Nsf have a chance of making it into the queue. > I would assume that the queue on idd.cise-nsf.gov would reach > back farther than that. I think the Cise-Nsf queue is good for at least an hour. > Since your solution appears to have worked, > though, the cause would seem to be somehow related to what you outlined > above. > > I will see if I can lengthen my queue a bit and try and get the "offset" > value up to 3600 seconds for iddrs3. Thanks for your help. You're welcome. Good luck. > Art > > Arthur A. Person > Research Assistant, System Administrator > Penn State Department of Meteorology > email: address@hidden, phone: 814-863-1563 Regards, Steve Emmerson Ticket Details =================== Ticket ID: VAP-368514 Department: Support LDM Priority: Normal Status: Closed