SLOW v.digit2, non-working v.digit

GRASS GIS GRASS GIS developer
1

On 13 July, boothl@pasture.ecn.purdue wrote to the lists complaining of
the SLOW performance of v.digit2 on a system using Solaris2.x.

On 26 July, mccauley@ecn.purdue.edu also mentioned the slowness of
v.digit2, and the inability of getting v.digit to run AT ALL on a system
running Solaris 2.x.

I can NOT get v.digit to work with an ALTEK board with an AC40 controller:
I have tried about EVERY combination of digitizer settings possible as
suggested by the Terry Baker document that brown@zorro.cecer.army.mil
forwarded to the GRASSuser's list on 10 August.
V.digit2 and an old style ALTEK driver works, but as with the above users,
I found it is VERY SLOW, so slow as to be barely usable..

Will there be any help forth coming on a solution to these problems, or do
we "pioneering" GRASS4.1/Solaris users have to wait for CERL to switch to
Solaris 2.x before these things are looked into? Are these GRASS4.1
problems, or are they Solaris 2.x problems?

What kind of performance are you non-Solaris user's getting out of the
v.digit* programs?

Any help at all would be appreciated.

Platform: SPARClassic
OS: Solaris 2.2
GRASS version: 4.1 w/updates
Backlog of work due to GRASS4.1 Systems Admin. tasks: enormous

^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
   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 20 Aug 93:

Will there be any help forth coming on a solution to these problems, or do
we "pioneering" GRASS4.1/Solaris users have to wait for CERL to switch to
Solaris 2.x before these things are looked into? Are these GRASS4.1
problems, or are they Solaris 2.x problems?

best I can figure, from watching vmstat and from observations of other
software, I estimate that the problem is 95% Solaris 2 and 5% v.digit.

The new v.digit is an excellent idea but it came at a really bad time
w.r.t. Solaris 2.

For any enterprising soul who wants to check this out, I would suggest
profiling the code (v.digit2/altek) and find out where the bottlenecks
are occurring (see 'cc -p', 'monitor', 'prof'). This would give most
folks a temporary fix until we can get the new v.digit figured out.

I agree with Ronald - THE PROBLEM IS SERIOUS. We at Purdue are dead in
the water w.r.t. digitizing. I'm know that boothl@ecn.purdue.edu has
done specific timings of v.digit2 (he's our main digit-dog), but to
just give you a rough idea, I would estimate that it would take about
30 minutes to an hour (start to finish) to digitize a 3 inch tall copy
of the Corps' Castle in stream mode.

--Darrell (glad that my own research involves point data) McCauley