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: "D. J. Raymond" <address@hidden> >Organization: NMT >Keywords: 200307041809.h64I9TLd018509 IDD LDM-6 Hi Dave, >I just started rtstats for you. Thanks! I really appreciate you reporting stats because it helps us keep track of IDD performance. No, on to ingest performance on heron: it is very bad at the moment: http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?HDS+heron.nmt.edu The differential latency from heron to yin.engin.umich.edu can be seen by doing the following: - open http://www.unidata.ucar.edu/staff/chiz/rtstats/siteindex.shtml?heron.nmt.edu - click on the 'topology' link for HDS: http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_topo_nc?HDS+heron.nmt.edu - click on the yin.engin.umich.edu link: http://www.unidata.ucar.edu/cgi-bin/rtstats/topolatency?heron.nmt.edu+yin.engin.umich.edu+HDS The time series plot from the last link shows that essentially all of the latency you are seeing is in the link from heron to yin. Since the latency plot for IDS|DDPLUS is exactly the same for HDS, I imagine that your ldmd.conf file has a single request line that looks more or less like: request WMO ".*" yin.engin.umich.edu The latencies being as high as they are (ranging up to 3600 seconds) warrants you splitting your feed request into at least two: request IDS|DDPLUS ".*" yin.engin.umich.edu request HDS ".*" yin.engin.umich.edu If your setup is like a number of others, this split will at least drop the latencies for the IDS|DDPLUS observational data down to low values. Another possibility is that the clock on heron is off by as much as 1000 seconds. We have been advising all sites running LDMs on PC OSes (e.g., Linux, Solaris x86, and FreeBSD) to set their clocks at least once per hour. One way that folks are doing this is by running 'ntpdate' out of 'root's cron. The University of Georgia uses 'rdate' in much the same way. After you split your feed, we will be able to see if your clock is, in fact, off since our expectation is that the latencies for the IDS|DDPLUS feed should drop to near zero values. If you continue to have high latencies after splitting your feed requests and adjusting your clock if needed, we will want to move you to a closer IDD relay node. I will keep an eye on your latencies for the next few days, but please let me know when you have finished splitting your feed request. Thanks in advance... Tom