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