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
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.