GRASS4.1/Solaris2.2 performance

GRASS GRASS user
1

Jean Boiven,

Now that you have got GRASS4.1 running on Solaris 2.2, I would appreciate
an appraisal of how it performs, compared to your previous version of GRASS
on another OS.

For those of you deciding whether to go with Solaris 2.2 in the near
future, here's news of another dud in the GRASS4.1/Solaris 2.2 story:

r.poly does not work, it bombs out with a "BUS error" message.

It is NOT a memory problem, it doesn't work on any size raster image.

As I have yet to run any software on the SPARClassic designed specifically
for Solaris 2.2, it would be premature to announce the machine and the
operating system failures, but GRASS4.1 is a pig on Solaris 2.2.

Let's see: mapgen4---- NO
     v.digit---- NO
     v.digit2--- almost useless
     r.poly ---- NO
     r.watershed -- NO
     XDRIVER -- compiles incorrectly
     built-in database capabilities -- none
Relative speed compared to GRASS4.0 on an 386i with SunOS 4.0.2:
        --same or slower
Relative speed compared to GRASS4.x on an IPX with Solaris 1.x:
        --MUCH slower
Oh well, it's free!

^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
   Ronald Thomas ^ ront@meeker.cfnr.colostate.edu
    Natural Resources Spec. (GIS) ^
     Resources Management Division ^ Phone: 303-586-3565 x285
      Rocky Mountain National Park ^ 700-323-7285 (FTS)
       Estes Park, CO 80517 ^ FAX: 303-586-4702
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^

2

Ronald Thomas (ront@niwot.CFNR.ColoState.EDU) writes on 1 Sep 93:

As I have yet to run any software on the SPARClassic designed specifically
for Solaris 2.2, it would be premature to announce the machine and the
operating system failures, but GRASS4.1 is a pig on Solaris 2.2.

granted, there are some SysV problems in GRASS that should not
have been there, but in fairness, I've had problem with speed
on a lot of applications. Not necessarily number crunching, but
IO related, things with overhead, named pipe stuff, etc. For example,
compare
   #include<stdio.h>
   int main() { system("ls"); }
on Solaris 2 versus Solaris 1. Repeat it and time it - big difference.

   v.digit---- NO
   v.digit2--- almost useless

these two are unfortunate. I am currently looking at v.digit2 to find
the bottlenecks. It appears to be incredibly slow when "processing"
after a stream is digitized, which I assume is just a few adds and
multiplies (coordinate conversion) and writing the output. Some may
say that I should spend my energies on v.digit, but I am really just
looking for a quick fix - v.digit2 works (barely) but v.digit doesn't
at all. (The symptoms seem to be the same among all Solaris 2 users
that I've spoken with.)

I'll post to grassp-list if I manage to speed it up any.

Relative speed compared to GRASS4.0 on an 386i with SunOS 4.0.2:

you have one of these!?! :o

--Darrell
James Darrell McCauley Dept of Ag Engineering, Purdue Univ
internet: mccauley@ecn.purdue.edu West Lafayette, Indiana 47907-1146, USA
bitnet: mccauley%ecn@purccvm UUCP: pur-ee!mccauley
*** avail. for full time employment 9/94-inquiries welcome (no hh, plz) ***

3

In info.grass.user you write:

Jean Boiven,

Now that you have got GRASS4.1 running on Solaris 2.2, I would appreciate
an appraisal of how it performs, compared to your previous version of GRASS
on another OS.

For those of you deciding whether to go with Solaris 2.2 in the near
future, here's news of another dud in the GRASS4.1/Solaris 2.2 story:

r.poly does not work, it bombs out with a "BUS error" message.

It is NOT a memory problem, it doesn't work on any size raster image.

As I have yet to run any software on the SPARClassic designed specifically
for Solaris 2.2, it would be premature to announce the machine and the
operating system failures, but GRASS4.1 is a pig on Solaris 2.2.

Let's see: mapgen4---- NO
   v.digit---- NO
   v.digit2--- almost useless
   r.poly ---- NO
   r.watershed -- NO
   XDRIVER -- compiles incorrectly
   built-in database capabilities -- none
Relative speed compared to GRASS4.0 on an 386i with SunOS 4.0.2:
      --same or slower
Relative speed compared to GRASS4.x on an IPX with Solaris 1.x:
      --MUCH slower
Oh well, it's free!

^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
  Ronald Thomas ^ ront@meeker.cfnr.colostate.edu
   Natural Resources Spec. (GIS) ^
    Resources Management Division ^ Phone: 303-586-3565 x285
     Rocky Mountain National Park ^ 700-323-7285 (FTS)
      Estes Park, CO 80517 ^ FAX: 303-586-4702
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^

We are working on GRASS4.1 for Solaris

One thing I can tell you right now is that
to compile XDRIVER substitute
   setpgrp(0, getpid());
by
   setsid()
Please tell me if it worked.
what about v.digit, r.poly and r.watershed?
do they compile and run incorrectly?
Olga

4

In info.grass.user you write:

In info.grass.user you write:

Jean Boiven,

Now that you have got GRASS4.1 running on Solaris 2.2, I would appreciate
an appraisal of how it performs, compared to your previous version of GRASS
on another OS.

For those of you deciding whether to go with Solaris 2.2 in the near
future, here's news of another dud in the GRASS4.1/Solaris 2.2 story:

r.poly does not work, it bombs out with a "BUS error" message.

It is NOT a memory problem, it doesn't work on any size raster image.

As I have yet to run any software on the SPARClassic designed specifically
for Solaris 2.2, it would be premature to announce the machine and the
operating system failures, but GRASS4.1 is a pig on Solaris 2.2.

Let's see: mapgen4---- NO
   v.digit---- NO
   v.digit2--- almost useless
   r.poly ---- NO
   r.watershed -- NO
   XDRIVER -- compiles incorrectly

I had no problems with the compile.

   built-in database capabilities -- none
Relative speed compared to GRASS4.0 on an 386i with SunOS 4.0.2:
      --same or slower
Relative speed compared to GRASS4.x on an IPX with Solaris 1.x:
      --MUCH slower
Oh well, it's free!

I get a good speed response on a SPARCserver 10 Model 512, it crashes in
a matter of microseconds. :slight_smile:

^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
  Ronald Thomas ^ ront@meeker.cfnr.colostate.edu
   Natural Resources Spec. (GIS) ^
    Resources Management Division ^ Phone: 303-586-3565 x285
     Rocky Mountain National Park ^ 700-323-7285 (FTS)
      Estes Park, CO 80517 ^ FAX: 303-586-4702
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^

We are working on GRASS4.1 for Solaris

One thing I can tell you right now is that
to compile XDRIVER substitute
  setpgrp(0, getpid());
by
  setsid()

Ronald Thomas was the one that told me this months ago.

Please tell me if it worked.
what about v.digit, r.poly and r.watershed?

v.digit

When starting to register points with the digitizer
"Digitizer read error, continue? (y/n) y"

I am talking with Sun about this, but they have to get back to me. I think
I need to set up the /dev/ttya port just like a bidirectional port (ala
a modem), because v.digit tries to write to the port and then read the
results, but no results come back. I think this is because the initialzation
does not get to the digitizer controller.

I found out this result from the output of truss(1m).

I cannot get v.digit2 to even work at all, whereas Ronald & Darrell (McCaulley)
get it work VERY VERY slowly. I get more digitizer read errors.

The rest of the programs all compile without any problems, well as least
gcc -traditional will report (it did not report the error with setpgrp
arguments).

do they compile and run incorrectly?
Olga

Aonther problem is that xclip4.1.exe cores out when trying to do anything.
This program is called by xgrass4.1.exe whenever you select anything
from its menus (except a grass shell, which works fine).

- Jim
--
[Jim] pirzyk@uiuc.edu ------------------------------------------
TAC & GrassNet System Administrator, US Army Corps of Engineers
Construction Engineering Research Labs, Champaign IL USA

5

Jim Pirzyk (pirzyk@cerl.cecer.army.mil) writes on 2 Sep 93:

v.digit

When starting to register points with the digitizer
"Digitizer read error, continue? (y/n) y"

same as I get.

I am talking with Sun about this, but they have to get back to me. I think
I need to set up the /dev/ttya port just like a bidirectional port (ala
a modem), because v.digit tries to write to the port and then read the

hmmm... I may see what our local gurus say about this (and there's
several of them, since Sun is so gracious to give us source code to
the OS :slight_smile:

I cannot get v.digit2 to even work at all, whereas Ronald & Darrell (McCaulley)
get it work VERY VERY slowly. I get more digitizer read errors.

I worked on this for a few hours today - see my post to grassp.
The slowness is actually with the interaction
with the monitor. I got significant speed-up by making the named pipes
local (instead of on an NFS mount). However, I still get faster
results on a sparc 2 running 4.1.1 while the named pipes are nfs-mounted.
So, the slowness is probably a Solaris thing with named pipes (or there's
a small chance that it's due to the XDRIVER or my network setup,
but I think that it's the fifos).

If you don't need the monitor while digitizing, then there's not a
problem. Just make sure your viewport area and digitizing area do not
intersect - everything is clipped and the speed is blazin'. (A fellow
Aggie spent 40-60 hours digitizing stuff from chromatography columns
and didn't care to view them right away-he was just a wee bit miffed
when he was sitting beside me today and I figured this last part out).

--Darrell

James Darrell McCauley, "Gig 'em Aggies" (too bad they're
Purdue Univ, West Lafayette, IN 47907-1146, USA on P-p-V this wk)
mccauley@ecn.purdue.edu, mccauley%ecn@purccvm.bitnet, pur-ee!mccauley
** avail. for full time employment 9/94-inquiries welcome (no hh, plz) **