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.
>From: Robert Leche <address@hidden> >Organization: LSU >Keywords: 200306201700.h5KH0eLd015285 Hi Bob, >Just to let you know..... >Ntp service is now running on host: hurricane.srcc.lsu.edu. Thanks for the update. Here is one for you: I have been ingesting HDS data from seistan on two different machines, one here at the UPC, and on at the University of South Florida. Both machines are experiencing the exact same kind of large latencies that ULM was seeing while ingesting the same feed from seistan. To see this, please take a look at the 'latency' plots for the HDS feed generated for zero.unidata.ucar.edu and metlab.cas.usf.edu: zero.unidata.ucar.edu: http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml?zero.unidata.ucar.edu metlab.cas.usf.edu http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml?metlab.cas.usf.edu This does seem to indicate that the feed problems are somewhere at or close to LSU. Exactly where, I can't say for sure. My next test will be to return metlab.cas.usf.edu's HDS feed to pluto.met.fsu.edu where the receipt latencies were near zero. I would like to then feed the HDS data _to_ seistan to see if the throttling is bidirectional. In order to really test this, I would need to shut off the HDS feed seistan is currently getting. Is this OK with you? Tom