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

[GEMPAK #JEK-967158]: ldm+dcgrib2

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.

  • Subject: [GEMPAK #JEK-967158]: ldm+dcgrib2
  • Date: Tue, 14 Feb 2006 11:15:26 -0700
Patrick,

Given the time frame you mention, I suspect that this is simply a matter
of your LDM receiving a large volume of data that had to be decoded
since you are connected to atm.geo.nsf.gov, which had intermittent
laser conectivity during the snowstorm. Also, that 17/18Z time
is a peak in CONDUIT data as well as other HDS models (RUC and GFS).
Basically, when a slug of data comes in, things are going to have to
work hard to digest it.

If this is an ongoing concern, then it may be more of a io throughput issue.

Steve Chiswell
Unidata User Support



Ticket Details
===================
Ticket ID: JEK-967158
Department: Support GEMPAK
Priority: Normal
Status: Closed