20000808: ADDE access to NOAAPORT GINI imagery at U. Georgia (cont.)

>From: "Thomas L. Mote" <address@hidden>
>Organization: University of Georgia
>Keywords: 200007172022.e6HKMuT11816 UGA McIDAS-X ADDE NOAAPORT GINI imagery

Tom,

>Gosh... thanks for all the effort.

No problem.  Usually things go a lot quicker than they did on your
machine.  The load average of 22+ was not helping things :-(

>I guess I haven't kept 
>up as well as I should have. I have had some help in the 
>past, but lost it this past year.

You are certainly not alone.  Far too few sites have decent system
administrators available.  That is one of the reasons why we help
out when we can.

>I wasn't aware that there 
>was a newer version of McIDAS, but I should have checked.

Not a newer version (yet, 7.7 is in the works); just a newer bug fix
release (actually, 8 since the last one that was installed).  I
don't announce these things because I have always felt like sending
too many of these things would be like spamming my sites.  I think
I will change this tactic with starting with the 7.7 release.

>Regarding Solaris. I thought the machine seemed slow, and I 
>was about to have our networking people come over and work 
>with me to install any new patches, etc. However, we are 
>discussing upgrading the system to Solaris 7. That might be 
>the best option.

Yes, I was going to suggest that that would be a good thing to do.
Solaris 5 is now rather dated.  I must warn you, however, that you will
most likely have to either rebuild all Unidata software or install
binary distributions, where available, when you make the move from 5 to
7.

>Although the machine is a Sparc 20, it is 
>a dual processor machine with 128MB of RAM, so it shouldn't 
>be that slow. 

Well, having two processors is good, but 128 MB or RAM is now simply
not enough when running newer software (OS and applications).  I
know that 128 MB used to seem like a lot of memory, but that is how
much I have on my machine at home (the one I am composing this reply
on), and I have been seriously considering adding another 128MB!

>I'll let you know when some of these problems are taken 
>care of.

OK.

>From address@hidden Tue Aug  8 21:27:18 2000
>Subject: Re: 20000808: ADDE access to NOAAPORT GINI imagery at U. Georgia 
>(cont.)


>See below for comments as I made changes...


re: I can't access your ADDE server from my machine(s) in Boulder
>OK, does that mean it would be impossible for anyone 
>outside UGA to be able to use my ADDE server?

Yes.

>How could we 
>determine whether this is something UGA is blocking? 
>Possibly I need to make a call to our networking people.

I will have to ask my system administrator about this tomorrow.
 
re: directory permissions
>I have changed the group permissions. Part of the problem 
>was that the mcidasd subdirectory was actually its own 
>partition for a while, then moved back into the /data 
>partition when I installed the new disk.
 
OK, but another part of the problem was that the group that 'ldm'
belonged to apparently changed sometime in January.

re: modify the LDM pqact.conf entry to switch to use of pnga2area
>Made the changes and checked the pqact.conf, looks OK.

Excellent.
 
re: change the request MCIDAS line in ldmd.conf
>OK. I did this as well. This looks a little strange to me, 
>as if we will only get the AREA files.

As of July 1, 1999 the only thing left in the Unidata-Wisconsin (MCIDAS)
datastream _is_ images.  And those are being converted from delta-encoded
products to PNG compressed ones.  This will cut down on the volume of
data in the feed, and then we will double it by doubling the temporal
frequence for the VIS, IR, and WV products (I have to check on the WV
ones to see if they are available every 30 minutes; stay tuned).

re: your machine was bogged down
>The load on the machine has been reduced 
>significantly, so it just finished running. I am now 
>starting to install some system patches.

OK, good.  I will try jumping on to see if the McIDAS update finally
finished.  A job that normally takes 10 minutes was stretching into
at least 4 hours due to the load.

re: GINI configuration files
>I believe I understand what you did in these files. I saw 
>the RESOLV.SRV file in the ~mcidas/workdata directory, 
>which is what i assume you meant.

Oops.  Yes, you are right.  I left off the 'workdata' part of the location
for RESOLV.SRV; sorry.

re: slowness of your machine
>It really shouldn't be that slow. If it's a problem, maybe 
>it is time for me to move the LDM over to an Ultra 1 
>machine I have that isn't used much anymore.
 
This machine should be OK for doing LDM stuff, but if you start trying
to run McIDAS or GEMPAK/GARP sessions on it, things will come to a
screaching halt.  One reason is the shorage of memory.  I imagine that
your system is doing an awful lot of swapping to disk, and this slows
things down tremendously.

re: sending GINI data to cacimbo
>It would be sent to cacimbo. I have an additional partition 
>that I would put the data on with about 6GB space.

OK, I understand now.  I don't know what the results of this would be,
by the way.

re: ADDE being accessible to the outside world
>Could it have anything to do with running NIS+? It doesn't 
>seem so, but I don't know...

I don't think so, but I will ask my sysadmin tomorrow.

Tom