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

20051214: ADDEIMAGE.xxx mods (cont.)



>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200512091601.jB9G1w7s009532 McIDAS Solaris 10

Hi Gilbert,

I just got back from a three day ski trip...

re: ADDEIMAGE.(USER|SITE|CORE)

>Sounds good! Thanks. I tried it, and it works!

OK.

>But...
>Now, I have found a bug in this latest version. When you use the GUI after 
>starting McIDAS, and disply your first satellite image with coordinates 
>based on a METAR site, it will display the upper left corner of the data 
>(in the case of the NASA set, you see a chunk of Alaska and the edge of 
>the Earth; on other datasets, it varies). Do it a second time and each 
>time thereafter, and it is fine.

Hmm...  I just tried this on my home McIDAS development machine and
do not see the problem you indicate.  I will have to dig deeper to
see why you are running into this problem.

>From address@hidden  Wed Dec 14 15: 37:59 2005

re: NIU's I2 connection may be hot, but ADDE access to data on weather3 is
glacially slow

>Can you do a traceroute back to me? I notified ITS, haven't heard back
>from them, but they are still tweaking the routes, I can tell.

Here is a traceroute from my home machine:

$ traceroute weather3.admin.niu.edu
traceroute to weather3.admin.niu.edu (131.156.8.48), 30 hops max, 38 byte 
packets
 1  maynardgkrebs (192.168.1.1)  1.208 ms  39.742 ms  7.123 ms
 2  dobiegillis.sugarloaf.net (192.168.191.1)  4.922 ms  3.282 ms  7.866 ms
 3  172.27.20.1 (172.27.20.1)  7.826 ms  4.469 ms  4.070 ms
 4  172.24.128.21 (172.24.128.21)  22.849 ms  25.273 ms  10.653 ms
 5  bcn-204-144-179-250.mric.net (204.144.179.250)  13.249 ms  15.768 ms  
13.146 ms
 6  bcn-204-144-179-237.mric.net (204.144.179.237)  18.351 ms  12.759 ms  
13.679 ms
 7  S-6-0-2-CB-1.rockynet.com (204.188.99.185)  112.254 ms  17.590 ms  25.723 ms
 8  cd2-se-3-0-0.rockynet.com (206.168.39.250)  25.582 ms  23.313 ms  18.698 ms
 9  cd3-fa-0-0.rockynet.com (206.168.230.3)  25.549 ms  23.788 ms  101.602 ms
10  f0-2.na01.b000530-0.den01.atlas.cogentco.com (38.112.18.253)  26.336 ms  
22.035 ms  33.128 ms
11  g1-9.core01.den01.atlas.cogentco.com (38.112.35.201)  32.816 ms  39.903 ms  
29.117 ms
12  p5-0.core01.mci01.atlas.cogentco.com (66.28.4.30)  53.700 ms  88.448 ms  
54.384 ms
13  p5-0.core02.ord01.atlas.cogentco.com (66.28.4.34)  57.765 ms  63.228 ms  
66.669 ms
14  p12-0.core03.ord01.atlas.cogentco.com (154.54.3.154)  197.357 ms  132.105 
ms  80.958 ms
15  206.220.243.106 (206.220.243.106)  94.021 ms  59.778 ms  71.545 ms
16  206.166.9.26 (206.166.9.26)  83.392 ms  115.968 ms  46.639 ms
     MPLS Label=16 CoS=0 TTL=1 S=1
17  2.130.7.209.rtc5.illinois.net (209.7.130.2)  81.496 ms  66.519 ms  56.350 ms
18  130.93.174.209.rtc5.illinois.net (209.174.93.130)  73.401 ms  71.618 ms  
53.073 ms
19  131.156.168.10 (131.156.168.10)  57.587 ms  89.540 ms  81.932 ms
20  * * *
21  * * *
22  * * *
23  * * *
 ...
30  * * *

Here is one from a Unidata machine:

traceroute to weather3.admin.niu.edu (131.156.8.48), 30 hops max, 40 byte 
packets
 1  flra-n140 (128.117.140.252)  1 ms  1 ms  1 ms
 2  gin-n243-80.ucar.edu (128.117.243.81)  1 ms  1 ms  1 ms
 3  frgp-gw-1.ucar.edu (128.116.254.250)  2 ms  2 ms  2 ms
 4  192.43.217.130 (192.43.217.130)  2 ms  10 ms  2 ms
 5  kscyng-dnvrng.abilene.ucaid.edu (198.32.8.14)  12 ms  12 ms  29 ms
 6  iplsng-kscyng.abilene.ucaid.edu (198.32.8.80)  22 ms  22 ms  22 ms
 7  chinng-iplsng.abilene.ucaid.edu (198.32.8.76)  25 ms  26 ms  26 ms
 8  mren-chin-ge.abilene.ucaid.edu (198.32.11.98)  34 ms  25 ms  34 ms
 9  131.156.168.33 (131.156.168.33)  28 ms  28 ms  28 ms
10  131.156.180.57 (131.156.180.57)  29 ms  28 ms  28 ms
11  * * *
12  weather3.admin.niu.edu (131.156.8.48)  29 ms  28 ms  28 ms

>From address@hidden  Wed Dec 14 21: 39:28 2005

>They just told me, "try now", in essence.

>From address@hidden  Thu Dec 15 12: 47:48 2005

>This is a message I got from our campus senior network administrator:

>>It (I2) is pretty much up and running. It will likely some down for a day
>>or two when some new equipment arrives.  Push it as hard as you can. (I know
>>this is conflicting with everything else I have ever told you).  I want
>>to see what it really can do.
>> Herb Kuryliw

>BWAHAHAHAHAHAHAHAHAHAHAHAHAHA. :-)

>Nooooooooo problem!!!!! :-D

>I have always wanted the NIMAGE, Level II NEXRAD, and CONDUIT (NMC model
>feeds). What do I have to do to get them and appropriate pqact.conf
>entries?

Of course, your pqact.conf entries would depend on what you want to do
with the data.  Example actions for the NIMAGE and NNEXRAD data would
be:

#
# Zlib compressed NOAAPORT GOES-East/West GINI images -- uncompres
NIMAGE ^satz/ch[0-9]/.*/(.*)/([12][0-9])([0-9][0-9])([01][0-9])([0-3][0-9]) 
([0-2][0-9])([0-5][0-9])/(.*)/(.*km)/
       PIPE    -close
       decoders/zlibg2gini -vl logs/ldm-mcidas.log
       data/gempak/images/sat/\8/\9/\1/\1_\2\3\4\5_\6\7

#
# Zlib compressed NOAAPORT GOES-East/West GINI images -- FILE
NIMAGE  ^satz/ch[0-9]/.*/(.*)/([12][0-9])([0-9][0-9])([01][0-9])([0-3][0-9]) 
([0-2][0-9])([0-5][0-9])/(.*)/(.*km)/
        PIPE    -close
        util/ldmfile.sh data/gempak/images/sat/\8/\9/\1/\1_\2\3\4\5_\6\7

I use the simple Bourne shell script 'ldmfile.sh' to FILE the images
instead of the FILE action supported by pqact since the latter does not
log the receipt of images.  You can find this script in the
pub/ldm/scripts directory of anonymous FTP on our FTP server,
ftp.unidata.ucar.edu.  NOTE: if you decide to use ldmfile.sh, you will
need to:

- put it in a directory in the PATH of your 'ldm' user
- change its mode to include execute privilege
- edit it to set parameters to match your setup

Here is an example action that uses pqact's FILE capability to file the
images in a directory hierarchy that GEMPAK users:

# Use this action to file everything
NEXRAD  ^SDUS[2357]. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...)
        FILE    -close  data/gempak/nexrad/NIDS/\5/\4/\4_(\1:yyyy)(\1:mm)\1_\2\3

The key thing to remember when ingesting these streams is that you need
to setup scouring of the data!

One last thing: v2005 McIDAS-XCD decoders do not handle the GRIB2 data
that is delivered in CONDUIT.  GEMPAK, on the other hand, handles it
nicely.

>And, add me to the relay site list to other Universities on the I2. I want
>to be an I2 relay of data for NIMAGE and CONDUIT, to start, and whatever
>else you can think of.

OK.

>From address@hidden  Thu Dec 15 12:48:57 2005

On Wed, 14 Dec 2005, helpdesk helpdesk wrote:

>> Gilbert,
>> Are you still having problems with the I2 connectivity? Thanks,
>> Dan K

>I haven't heard back, but judging from what I heard from others, it has 
>been fixed. I will let you know though if this is not the case.

As I mentioned at the beginning of this email, I was out of the office
starting midday on Wednesday and then all day Thursday, Friday, and
Saturday.  I am back now, and see the same glacially slow access to
weather3 from my home machine.  I just tried from one of the machines
at Unidata, and the access is fast.  Does this mean that sites _not_ on
I2 will experience long delays in ADDE access to weather3?

>From address@hidden  Fri Dec 16 00:18:04 2005

>Hi Mike,

>I suspect my statement below still stands, but just to make absolutely 
>sure, I want our chief network architect, Herb Kuryliw, to take a look at 
>this. Herb, read it over and let us know what you think. Can you get me a 
>gig for no extra cost and justify it by letting you use much of it for 
>experimentation? A very, very longshot, but I'm about longshots...

>> Hi Mike,

>> Any chance you'll have gigabit connections to your LDM server, and if
>> so, can you support large MTU (jumbo frames)?  We've been experimenting
>> with a 9000 byte MTU and we'd like to do end-to-end bandwith testing
>> with a few geographically distributed sites when possible.
>
> Nah. We can only afford 100 mb to the office right now, although in the next 
> few years I suspect they'll offer upgrades to 1 GB. Our I2 connection is 1 GB 
> to start, but I just learned that to get it, we may have to give some of that 
> bandwidth to partners who are getting us this connection at a very low cost. 
> So, the answer is no for now...wish I could do that, though. Sorry. :-(

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

>From address@hidden  Mon Dec 19 10:11:24 2005
To: helpdesk helpdesk <address@hidden>
cc: General Support <address@hidden>
Subject: Re: Poor connectivity to weather3.admin.niu.edu, port 112

On Thu, 15 Dec 2005, Gilbert Sebenste wrote:

> On Wed, 14 Dec 2005, helpdesk helpdesk wrote:
>
>> Gilbert,
>> 
>> Are you still having problems with the I2 connectivity? Thanks,
>> 
>> Dan K

Hi Dan,

It's fine now via I2, but now port 112 to weather3.admin.niu.edu is still 
painfully slow via the ICN, even though that line is (poly)unsaturated
with traffic. Can you look into it?

>From address@hidden  Tue Jan  3 15:38:25 2006

On Sun, 18 Dec 2005, Unidata Support wrote:

> re: NIU's I2 connection may be hot, but ADDE access to data on weather3 is
> glacially slow
>
>> Can you do a traceroute back to me? I notified ITS, haven't heard back
>> from them, but they are still tweaking the routes, I can tell.

Tom,

They are now catching up. But, here is a list of blocked ports:

Blocked Port    Action Taken                                 Date 
Login | 
Reason--------------------------------------------------------------------------------
  TCP 3306        blocked at the edge - incoming and outgoing  3/30/2005 
NE | to prevent scanning for MySQL exploit
  UDP 1026        blocked at the edge - incoming               4/20/2005 
NE | to prevent scanning for Messenger
  UDP 1027        blocked at the edge - incoming               4/20/2005 
NE | to prevent scanning for Messenger
  icmp            blocked at the edge - incoming               4/20/2005 
NE |
  TCP 3127        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 1434        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 1433        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 135         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 136         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 137         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 138         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 139         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 445         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 593         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 42          blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 5000        blocked at the edge - incoming and outgoing  4/20/2005 
NE | to prevent UPNP exploit
  TCP 6129        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 1433        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 1434        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 135         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 136         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP netbios-ns  blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP netbios-dgm blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP netbios-ss  blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP tftp        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 445         blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP snmp        blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP snmptrap    blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  TCP 6660-6670   blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 6660-6670   blocked at the edge - incoming and outgoing  4/20/2005 
NE |
  UDP 1900        blocked at the edge - incoming and outgoing  4/20/2005 
NE | to prevent UPNP exploit