[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20051214: ADDEIMAGE.xxx mods (cont.)
- Subject: 20051214: ADDEIMAGE.xxx mods (cont.)
- Date: Sun, 18 Dec 2005 10:33:18 -0700
>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