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 David and Pete, Pete wrote: > Are you using a split feed to get conduit data or a single request line? > We've found > that splitting the feed into multiple request lines can have a huge impact on > getting > CONDUIT data with much smaller lags than you are seeing on freshair2. > > We're using a 10-way split and our lags have recently been less then 30-60s > even with > the additional data from the GFS FV3 update. I believe that Pete's comment may be in the right neighborhood for figuring out what may be going on. Compare rtstats volume plots for two UWashington machines that are REQUESTing CONDUIT with our machine that REQUESTs CONDUIT from NCEP and then relays the data to the accumulators for our top level IDD relay clusters: freshair1.atmos.washington.edu http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?CONDUIT+freshair1.atmos.washington.edu freshair2.atmos.washington.edu http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?CONDUIT+freshair2.atmos.washington.edu conduit.unidata.ucar.edu http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?CONDUIT+conduit.unidata.ucar.edu A visual comparison in the receipt volumes between the machines freshair1 and conduit indicates that the volumes are essentially the same. The same comparison between freshair2 and either/both freshair1 and conduit shows that freshair2 is receiving less volume. This lead me to compare receipt latencies between freshair1 and freshair2: freshair1.atmos.washington.edu http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?CONDUIT+freshair1.atmos.washington.edu freshair2.atmos.washington.edu http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?CONDUIT+freshair2.atmos.washington.edu This comparison shows that the receipt latencies on freshair1 are, for the most part, very low, while the latencies on freshair2 are periodically high to the point that products are likely to be missed. Now the question is why are the latencies on freshair2 so much different than the latencies on freshair1? Pete's questioning of how CONDUIT is being REQUESTed on each is the first place to start in this investigation. I expect that the most likely answer will be that there are more splits to the feed REQUEST on freshair1 than on freshair2. David: What are the REQUEST line(s) for CONDUIT both freshair1 and freshair2? Also, what are the LDM queue sizes on freshair1 and freshair2? Comment that is somewhat aside: It may be a good idea to also REQUEST CONDUIT from freshair1 on freshair2 and visa versa as this will cause products received on one earlier than the other to be sent to the other. We cross REQUEST on all of the accumulators (front ends) for our IDD relay clusters as a matter of course. 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: VXV-940104 Department: Support CONDUIT 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.