GRASS4.1/Solaris2.2 performance

[Jim Pirzyk]

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

>>^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
>>   Ronald Thomas                         ^  ront at 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 at uiuc.edu ------------------------------------------
TAC & GrassNet System Administrator, US Army Corps of Engineers
Construction Engineering Research Labs, Champaign IL USA