[LDM #QEL-970387]: LDM at NOAA

Hi Russ,

re:
> We are still having problems with our LDM.  I don't think it has
> anything to do with our receiver because all was working fine ( last
> year ) before we upgraded our server to RHEL6 and installed the latest
> vesion of LDM and McIDAS-XCD.

Assuming that the machine running your NOAAPort ingest and LDM has
had the needed kernel tuning done (modifications to /etc/sysctl.conf),
and assuming that your machine is fast enough (this should be the case)
then the most likely cause for the 'Missing fragment' messages would
be noise in the ingest.

We noticed a huge increase in Gap (Missing fragment) messages when the
NOAAPort SBN was upgraded last September.  I spent a LONG time trying
to figure out what was causing our ingest problems and implementing
tweaks that included:

- realignment of our NOAAPort dish

- removal of a plastic cap that covered the dish-side opening to the
  LNB

- examining all cable and connectors in the signal path from the
  LNB to the Novra S300N

- replacement of network switches that we were using to split
  the feed from our two S300Ns

- re-examination of our monitoring procedures

  We were interrogating the S300N once-per-minute for status info.

A combination of our experimentation and feedback from other NOAAPort
ingest sites had led us to believe that better signal quality
(as measured by the C/N reported by the S300N), would result in
less Gap messages being seen.  By examination of the occurrence of
Gap messages as a function of C/N led me, at least, to believe that
if we could get our C/N above about 16.4, then our ingest would be
mostly problem free.  This belief was partly confirmed by less numbers
of errors seen as we slowly improved our signal quality, but there
was still something else going on.  On a hunch we turned off all
interrogation of one of our S300Ns and left our normal interrogation
on the other unit.  The number of Gap messages seen on the unit
not being interrogated plummeted dramatically.  We shared this
observation with our local WFO and with one of the commercial vendors
of NOAAPort ingest packages.  To our surprise and relief, the
commercial vendor verified that they too had observed that interrogation
of the S300Ns would cause problems with the ingest.  They also let
us know that they see big differences in the ability to ingest NOAAPort
from different S300Ns all of which were receiving the exact same signal.
Their unofficial conclusion was that error free ingest varied widely
from S300n to S300n -- there are good units, and there are bad units!
Luckily, they were/are in contact with Novra and shared this observation.
Furthermore, they allowed Novra to setup a test NOAAPort ingest at their
facilities so that Novra engineers could more closely examine what was
happening (Novra was _not_ ingesting NOAAPort before this).  Novra's
testing resulted in a new release of the firmware for the S300n, v2R15.

What to do?  We recommend that you:

- stop interrogating your S300N if you are, in fact, doing so

  The monitoring I am speaking of is using the Novra utility 'cmcs'
  to get status information.

- upgrade your S300N to the latest version of the firmware

- getting your antenna alignment checked and tweaked

re:
> What I'm seeing in the logs is hundreds of messages like:
> 
> Jul 21 14:39:00 fos2-cip readnoaaport [32397] ERROR: Missing fragment in 
> sequence, last 0/392344050 this 6/392344050
> Jul 21 14:40:08 fos2-cip readnoaaport [32391] ERROR: Missing fragment in 
> sequence, last 2/72581026 this 2/72581027
> Jul 21 14:40:31 fos2-cip readnoaaport [32393] ERROR: Missing GOES fragment in 
> sequence, last 533/298108 this 541/298108

Yup, these are the kinds of errors I was referring to above.

re:
> Jul 21 15:04:49 fos2-cip readnoaaport [32397] ERROR: [GB2PARAM.C:89] [GB -1] 
> Couldn't get parameter info: disc=0, cat=19, id=233, pdtn=0

This is totally different... the GB messages are basically saying that the 
GRIB2 tables
that are being used by the ingest package do not have entries for some of the 
parameters
in the datastream.  The GB errors are typically seen for products in the NGRID 
datastream
and sometimes in the HDS datastream.  The "solution" is to make sure that you 
are
running a current version of our NOAAPort ingest software, but this will not 
take care
of the problem entirely as the contents of the NOAAPort SBN is a moving target. 
 We
try to stay on top of updating the tables, but...

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: QEL-970387
Department: Support LDM
Priority: Normal
Status: Closed