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.
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