[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #MNK-989154]: comparing, contrasting two ldm servers



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