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

[IDD #ZSJ-835116]: missing gfs grids on NGRID

Hi Gilbert,

re: NOAAPort ingest of NGRID data
> Interesting. I was wondering if that had anything to do with the
> switchover of satellites from AMC-4 to AMC-2.

That was my first thought, but some quick rtstat checking showed that
the problem lay elsewhere.

> On my NOAAport system,
> with a marginal LNB that now works pretty much fine all the time since it
> is warm out now, I am seeing a steady signal, with the exact signal
> strength, just as I saw when it was on AMC-4.

I always like progress :-)

> I would be very curious to
> know why all 3 of you (LSU, SSEC, UNIDATA) had the reception problems you
> did, if it was the NOAAport software, or equipment issue, when you figure
> it out.

There were three unrelated things going on:

1) we had our NOAAPort ingesters down for service on our Dell 2650s and to
   troubleshoot a very strange problem that is related to Ethernet when a PC
   when a PCI card is in use.  Our current NOAAPort ingest systems are also
   ingesting GOES data (one ingests GOES-East; the other GOES-West; the other
   GOES-South (GOES-10)) using a 5V PCI SDI card from SSEC (repurposed
   NOAAPort ingest cards for the pre-DVBS NOAAPort broadcast).  The 2650s
   do not support a 5V PCI slot, so we had to buy Magma expansion chassis
   that allow use of the 5V cards.  This hardware combination in combination
   with a new Broadcom Ethernet driver for Solaris x86 v10 was causing
   system lock-ups.  Mike Schmidt rolled out of the Broadcom drivers back
   to Sun ones (that don't support jumbo frames) last night (ending at 1:40
   am this morning, no less).

2) we don't know why the SSEC DVB-S ingest systems are not receiving the
   full complement of NGRID data (nwstg2).  I will attempt to get a login
   to those machines to do some troubleshooting next week.

3) the LSU NOAAPort ingest machine has been getting all of the NGRID data
   with no problems.  I do not yet know why it was not supplying the NGRID
   data that the SSEC ingesters were missing.

4) at some point in the past, we had turned off redundant ingestion from our
   NOAAPort machine at the ATM offices of NSF in Arlington, VA.  My guess was
   that this was done when there were TI/noise problems back there or when
   the machine, idd.cise-nsf.gov, was too overloaded by IDD requests to
   properly service the NOAAPort feeds

So, you can see that this was a "comedy" (no hahas from me) of errors/problems.

> By the way, if all goes well and weather permitting, we swap out the LNB
> and struts and go "live" for real, finally, on Wednesday, the day we get
> "StormReady" recertification from the NWS! We've now figured out the
> obvious: an analog LNB with non-digital, non-PLL capabilities will NOT
> work with NOAAport. And why oh why our analog LNB works well when it is
> warm out and not when it is cold (should be the reverse) is beyond our
> broadcast engineer's grasp.

I don't understand it either.  The only thing that remotely resembles this
behavior is a cold solder joint somewhere.

> It's happened on two of our analog LNB's,
> too. The Norsat 3120 LNB we have will assure us that problem won't ever
> happen again, once it is installed.

Excellent.

re: service interruption
> So this leads me to a suspicion I have had: If a data feed, let's say
> IDS|DDPLUS, has dropouts from satellite receiver/LDM A, but has an
> alternate to get data from perfectly working satellite receiver/LDM "B",
> the LDM is supposed to grab the missing data from "B" automagically, right?

Correct.

> If true, I've had suspicions that hasn't worked, but I haven't been able
> to prove it. Or am I misreading what you are saying in what you are seeing
> as the problem?

This automatic failover _does_ work as designed.  Redundant ingestion of
NOAAPort feeds on the accumulators for our toplevel IDD cluster has allowed
us to work on pieces of the system without worrying about the consequences
for three years now.

> Again, I have nothing solid on this, but I'm just curious.

Please let me know if you have questions on anything above.

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: ZSJ-835116
Department: Support IDD
Priority: Normal
Status: Closed