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 Susan, re: > We are trying to decommission an old LDM server and replace it with a newer > model. We > are running LDM on both of them with identical data feeds There are issues on > the new > server, however. There are big differences in the file sizes of the "same" > files; the > ones on the new server are much larger. The new server drops some frames in > surface > data, even though the file sizes are larger. Some questions to begin: - what are the names of your old and new servers? - are they both reporting real-time statistics to us? The NCSU machines we are getting stats from are seen in: http://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex cronos-ldm.meas.ncsu.edu [6.7.0] flightrisk.meas.ncsu.edu [6.6.5] measwx.meas.ncsu.edu [6.10.1] newflux.meas.ncsu.edu [6.9.8] I would guess that measwx.meas.ncsu.edu is your new machine. From your comment below, I would guess that the old machine is flightrisk.meas.ncsu.edu. Is this correct? - what are the sizes of the LDM queues on your old and new machines? - specifically what are the files that are larger on the new machine than on the old? re: > Are there some settings I could tweak on the new server that might help > prevent the > apparent dropped frames? The typical reasons that an LDM might not get/process all of the data being REQUESTed are: - latencies in receipt of product(s) from an upstream host exceed the maximum number of seconds that the upstream's LDM queue can hold - the LDM queue size on the receiving machine is not large enough to hold received data long enough for it to be processed out of the queue - there is some error in processing data out of the receiving LDM's queue re: > Is there enough difference in the versions of LDM (or GEMPAK) decoders that > might be the > reason for differing file sizes and times? The old 6.6.5 and new 6.10.1 versions of the LDM should be able to get the same number of products/volume for identical feed REQUESTs from identical upstreams. There well could be a difference in GEMPAK decoders that accounts for the processing of more of the products that are being received. re: > Old server is running ldm 6.6.5, gempak 5.10.1. New server is ldm 6.10.1, > gempak 6.4.0 I would venture to guess that the biggest reason for the difference in number/volume of products processed is the newer version of GEMPAK. Please review the GEMPAK decoder log files to see if you can see any systematic problems (typically in the ~ldm/data/gempak/logs directory). By the way, GEMPAK 6.4.0 is not the current release of GEMPAK. You may want to consider upgrading it to the latest release. re: > thanks No worries. Please keep us informed about what you find in the GEMPAK log files on the old and new machines. 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: MNK-989154 Department: Support LDM Priority: Normal Status: Closed