19990720: use of OS/2 to run McIDAS (cont.)

>From: "David J. Travis" <address@hidden>
>Organization: University of Wisconsin-Whitewater
>Keywords: 199907201834.MAA28226 McIDAS

David,

>Thanks for the quick response.  We are using Red Hat Linux as well. I have
>discussed our Linux display problems a bit with Don Murray but let me bring
>you up to speed:

OK, I didn't know/remember that you and Don were talking about specific
Linux issues.

>1. The linux display is extremely slow in bringing up new images/loops
>compared to the OS/2 display.

And the machines are of comparable speed?  Is the data local on the Linux
box, or is it accessing data via NFS?

>Also, we would like to occasionally run
>Netscape and a few other software packages on the same machine and they
>seem to come up at a very slow pace compared to most of our other
>computers.

I can compare my 200 Mhz Linux machine with a 200 Mhz OS/2 box that
is Don's office.  My experience is that, for local data, Linux is
at least as fast as OS/2 if not faster.  Also, bringing up Netscape
on my machine takes about 10-15 seconds.  After it is up, it runs
pretty fast.

>Keep in mind that we use McIdas primarily for classroom display
>and in order to get through my lectures in a timely manner I need to be
>able to bring up new images and animation loops quickly while also being
>able to bring up Netscape to show data from other web sites.  

I understand.

>2.  We relay the signal from our classroom display to a display in a nearby
>hallway on a large 29" monitor.  Since we've switched to the linux machine
>the monitor cannot handle the video feed.  This seems to be a function of
>the resolution required by the Linux machine to run McIdas and the fact
>that the monitor cannot handle the resolution.

Actually, you can adjust the XFree86 settings for the video on Linux
to just about anything that you want.  If OS/2 can run on the hardware
and create the display you want, then Linux can as well.

>Don Murray and I fiddled
>for a while a couple weeks ago to try and reduce the resolution down to a
>level that the monitor could handle (one comparable to what we have on our
>OS/2 machine) but we had no luck.  

Resolution is one thing, refresh rate is something else.  My experience
with things like Xconfigurator and XF86Setup is that you typically choose
a resolution and then the program tries to maximize the refresh rate
supported by the video card.  This typically gives the most stable display.
Your problem is undoubtedly that the 20" monitor will only support refresh
rates up to some maximum.  Do you know what this is?

>3.  We have batch files written on our OS/2 machine which automatically
>runs a movie of the most recent IR, VIS, and Water Vapor loops and updates
>them automatically as they come in.  I have had no luck creating such loops
>on our Linux machine (due to my inexperience in programming and finding my
>way through a unix environment).

Are the loops on the OS/2 machine in a McIDAS OS/2 session?  Are you then
slaving the display of the McIDAS-OS2 session out to the monitor? Or
are you creating GIFs (tm) that are then animated?

>If I have to constantly go in and
>manually update the loops in order to refresh them it makes the use of the
>monitor in the hallway very inefficient (especially on weekends!).

McIDAS-X can run these ROUTE PP BATCH scripts by appropriately setting
up a couple of files that can be run from the user running the LDM on
the Linux box.  This is dealt with in the online McIDAS-X documentation.

>Currently I have taken our Linux machine down from our classroom display
>location and housed it in a separate lab where it is acting as the primary
>ingestor for the datastream.  It then relays the data to our OS/2 machine
>which successfully displays the imagery in the classroom and in the nearby
>hallway.  

OK, it sounds like you are showing the McIDAS-OS2 session on the display
system in the hall.

>I agree that the linux machine should do the superior job and have not
>given up on it.  It has twice as much ram and a much faster chip.

Then it should be a LOT faster!

>In all
>likelihood it hasn't been set up properly or my lack of experience with
>unix hasn't allowed me to go in and improve its display performance.  I
>don't know if there is a solution to the hallway display problem since
>turning down the resolution of the screen would obviously reduce the
>performance of the display in the classroom.

Not necessarily.  What you need to strive for is a resolution that the
monitor can handle AND a refresh rate that the monitor can handle.
This takes a little playing with the video configuration on Linux, but
it is doable.

>Hope this all makes sense to you. 

Yes, it does.

>For the above reasons I'm probably going to continue using OS/2 as the
>primary classroom display until it becomes inoperable.

There is no harm in this.

>However, in the
>meantime I hope to get more comfortable with using Linux and hope to get
>that system displaying more efficiently.

Please ask for help when you get to that stage (after our training workshops
are over, that is :-)

>If you have any suggestions that
>you might want to offer I'm certainly eager to listen and make attempts to
>improve things.

After our workshops are over I will have more time to address these issues.

>From your e-mail it sounds like it's inevitable that the
>OS/2 system will eventually have to be replaced.  

Yes, this _is_ inevitable.

>Thanks in advance for your help.

You are welcome.

Tom

>From address@hidden  Tue Jul 20 21:24:17 1999

Thanks for the latest response.  I will try to work on finding answers to
each of the questions you've raised and then get back to you after the 
workshops are done.  Thanks as usual for your interest in helping me 
solve these problems.  The support you guys provide is unbeatable.

David