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: Unidata User Support <address@hidden> >Organization: Unidata Program Center/UCAR >Keywords: 200307021823.h62INMLd020225 LDM-6 upgrade Hi John (and Alan), Last month, maelstrom2 was successfully upgraded to LDM-6 and configured to request data from atm.geo.nsf.gov. After completing the upgrade, I asked Alan about upgrading maelstrom to a current LDM-6 release (it is currently running LDM-5.0.6). Since I see that maelstrom has not been upgraded, I am revisiting the issue of whether you intend to replace data IDD data ingestion on maelstrom with that on maelstrom2. If not, I would like to encourage you to upgrade the LDM on maelstrom to LDM-6 as it is much more efficient than LDM-5. We are willing to do the upgrade for you if given appropriate logins. Please let us know if you would like us to proceed. As far as the LDM-6 installation on maelstrom2 is concerned, the real time statistics that it is reporting back to Unidata show that its clock is not being set correctly. The latency plot for the IDS|DDPLUS data effectively shows the clock drift: http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?IDS|DDPLUS+maelstrom2.meteo.mcgill.ca For reliable IDD data ingestion, it is important to keep one's clock set accurately. As the clock difference between the receiver and upstream host(s) increases, so does the likelihood that data will not be delivered correctly (the LDM embodies the notion that data more than one hour old is not useful, so it is not sent). As I recall, setting the clock on maelstrom2 with ntpd or ntpdate has problems due to firewall issues (?). Cheers, Tom Yoksas