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

[TIGGE #UHK-328521]: Corrupted product at ECMWF via LDM ?

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: [TIGGE #UHK-328521]: Corrupted product at ECMWF via LDM ?
  • Date: Tue, 21 Aug 2007 09:50:19 -0600
Manuel,

> Don't worry, the faulty GRIB was not at encoding. Doug sent his version
> of the field and it was correct (same as yours).
> 
> Therefore, I have only two candidates for causing such corruption:
> either LDM or the disk. Corruption could have happened when copying data
> from the network into the LDM product queue or copying data from the LDM
> product queue to disk. We scanned the logs but couldn't find any problem
> with the disk subsystem...
> 
> I did report the problem to Unidata support
> (address@hidden), but have not heard anything from
> them. I did not get the automatic e-mail that assigns a token for
> incident reports. I copy them this e-mail again.

The LDM relies on TCP to correctly transmit data: it doesn't do any
error-detection or error-correction of its own.  TCP is excellent in
this regard, but it's not perfect: the probability of an incorrectly
transmitted byte is extremely small -- but not zero.

Can you put an upper bound on the error rate?

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: UHK-328521
Department: Support IDD TIGGE
Priority: Emergency
Status: On Hold