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

[IDD #IVG-583515]: RE: EXT :20141114: NOAAPort relay Machine Set up at NG

Hi Heather,

First, it was nice to "meet" you yesterday (phonewise anyway)...

re:
> I have attached your file.  Next time you can also just allow x-forwarding
> and start firefox and email to yourself.  I don't see why that wouldn't work!

OK.

re:
> We will chat at 9:00 your time also!

As a follow-up to our phone conversation yesterday, I can let you know that:

- a 'notifyme -vl- -h 208.24.128.84'

  This works, but the output listing seems very slow for the volume/number
  of products that should be flowing through 208.24.128.84.

- even though 'notifyme' demonstrated that we (gale, oliver, emo, agg1) are
  ALLOWed in your machine's ~ldm/etc/ldmd.conf file, and we can somehow get
  through the NG firewall, a feed REQUEST in ~ldm/etc/ldmd.conf results in
  very little data being transferred

  I setup a REQUEST for ANY from 208.24.128.84 on gale.unidata.ucar.edu and
  have let the LDM run overnight.  The volume of data for each NOAAPort-derived
  feed is much less than what should be available.  To see this, compare
  various feed volumes on gale with volumes from one of our NOAAPort ingest
  machines:

gale.unidata.ucar.edu
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex?gale.unidata.ucar.edu

lenny.unidata.ucar.edu
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex?lenny.unidata.ucar.edu

  Since the NEXRAD3 feed is one of the most continuously populated data streams,
  compare volumes of it between the two machines:

NEXRAD3 received on gale from your machine:
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NEXRAD3+gale.unidata.ucar.edu

NEXRAD3 received in the NOAAPort SBN on lenny:
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NEXRAD3+lenny.unidata.ucar.edu

  The large difference in data volumes indicates that whatever is being done
  securitywise at NG for the REQUEST from gale (e.g., going through a proxy; 
deep packet
  inspection and rewriting the IP address in the REQUEST; etc.) is seriously
  limiting the data that is transferred.

Quite frankly, the way that things are setup right now is preventing and will 
continue
to prevent 208.24.128.84 from being a viable input into the IDD.  Is there 
anything
that can be done in NG to improve this situation?

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