[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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.