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

[IDD #GOK-818269]: Help -- NEXRAD3 feed no longer working, along with some GOES imagery from UNIWISC

Hi Marcus,

re:
> GOES 11 data should be from UNIWISC, as we are getting GOES 12 data fine from 
> them.

Correct, GOES-11 images will be from the UNIWISC datastream.  I comment on 
NIMAGE
since your previous note specifically mentioned EAST-CONUS and WEST-CONUS which
should be populated by images from the NIMAGE datastream.

If you are not getting the UNIWISC GOES-11 data, things are very odd because the
GOES-12 images are significantly larger than the GOES-11 ones.
 
re:
> The others are indeed NIMAGE data...I had shut this down due to latency 
> problems.

OK.

re:
> Yes, I had removed the lightning data request after your email.

Very good.  I see that the last request for LIGHTNING from gwoemul was
yesterday:

<from ~ldm/logs/ldmd.log on the idd.unidata.ucar.edu cluster node feeding you>

Sep  2 17:39:17 uni14 gwoemul.wiu.edu[25253] WARN: Empty wanted/allowed 
product-class intersection for gwoemul.wiu.edu: 20100902223915.737 TS_ENDT 
{{LIGHTNING,  ".*"}} -> <nil>

re:
> My point was that I do indeed realize that the ldm server needs to be
> restarted after changes to ldmd.conf.

Very good.

re:
> As far as latency goes, yes, we were having some issues, but were able
> to get most of what we needed a few months ago even with the latency problem.

What jumped out at me this morning was the very high latency for the IDS|DDPLUS
data.  After reviewing one of your previous emails, I see that you are 
requesting
this feed as part of WMO:

REQUEST WMO ".*" idd.unidata.ucar.edu
REQUEST NEXRAD3 ".*" idd.unidata.ucar.edu
REQUEST UNIWISC ".*" idd.unidata.ucar.edu
REQUEST FSL2 ".*" idd.unidata.ucar.edu
REQUEST DIFAX ".*" idd.unidata.ucar.edu

WMO is a compound feedtype.  It is the combination of IDS|DDPLUS (a relatively
low volume feed) and HDS (a relatively high volume feed).  You should be
able to significantly cut the latencies for IDS|DDPLUS by splitting the
REQUEST from WMO into two disjoint REQUESTS:

change:

REQUEST WMO ".*" idd.unidata.ucar.edu

to:

REQUEST HDS ".*" idd.unidata.ucar.edu
REQUEST IDS|DDPLUS ".*" idd.unidata.ucar.edu

After doing this (and restarting the LDM) you should be able to get the
observations contained in IDS|DDPLUS in a timely manner.  It is likely,
however, that the model output in the HDS feed will continue to have
large latencies.

re:
> This is why I want to limit the NEXRAD3 feed to just a few sites and
> products.  But perhaps the network issue has gotten worse.

Let's find out more about the network issue by splitting your WMO
feed as I indicate above, while at the same time commenting out
any request for NEXRAD3.

re:
> I have been trying to resolve this issue with our network people here,
> but bandwidth here is hard to come by.

The amount of bandwidth needed to get IDS|DDPLUS, FSL2 and UNIWISC is
relatively small.  The amount of bandwidth needed to get NEXRAD3, NIMAGE
and HDS is relatively large.

re:
> This email is being forwarded to our security specialist (Gary Douglas),
> as he needs to open a path for you.   His request for information is at
> the end of this email.
> 
> Please provide him him any additional contact information that he needs.

Here is that snippit:

> From: "Gary Douglas" <address@hidden>
> To: "Marcus L Büker" <address@hidden>

> I am going to need some information to set this up. I have included
> it below.

> Local Contact: Marcus Buker
> Vendor Name:
> Vendor Contact:
> IP: 143.43.212.26
> Access Hours: 8am-6pm weekdays till 9/24 (suggested)
> 
> To add this VPN, I have to go through Change Management. This committee
> meets on Wend afternoons. I will put in this request today to set this up
> Thur morning. If you need this sooner please let me know.
> 
> I have put the access hours on from 8-6 for two weeks. If you need this
> for more time or in the future, all we need is a ticket. I have a standard
> change to adjust access hours for vendor vpn's without having to get change
> management approval. 

I guess we (Unidata Program Center/UCAR) are the "Vendor", so:

Vendor Name:    Unidata Program Center/UCAR
Vendor Contact: Unidata User Support/Tom Yoksas
IP:             128.117.140.62 needs SSH access to 143.43.212.26
Access Hours:   24/7 for a short period of time is preferred (it is hard
                to schedule work on end-user machines, so open access is
                useful)
Access Type:    SSH

Reason for access:  We would like to be able to run some tests to see where
                     the network bottleneck(s) is(are).  If it is already
                     known that throttling of LDM connections is being done
                     (via some sort of a "packet shaper") then we don't really
                     need login/SSH access to gwoemul.wiu.edu.

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