I have been poking around a bit with v.digit2 (calcomp)
and solaris 2 (there's have been complaints on grassu
about it being incredibly slow and v.digit [new one] not
even working at all).
I have found that if I digitize outside the boundaries
of my monitor that the slowness all but goes away. Thus,
the incredible slowness is most likely due to
the overhead of using named pipes.
I'll report more as I make discoveries.
--Darrell
[
Olga or whoever is reading grassbugs: consider this a bug report
on slowness of named pipes under Solaris 2, or maybe a mild complaint
about this scheme of communication 
]
Darrell McCauley (mccauley@ecn.purdue.edu) writes to grassp-list on 2 Sep 93:
I have found that if I digitize outside the boundaries
of my monitor that the slowness all but goes away. Thus,
the incredible slowness is most likely due to
the overhead of using named pipes.
!! MAKE FIFOs LOCAL !! MAKE FIFOs LOCAL !! MAKE FIFOs LOCAL !!
here are some timings for v.digit2 using n=800 points: The first
number is at the "processing.." stage. The second number is the time
required after "Do you accept this area line?"
+ machine time 1 time 2 Remarks
a LX 12 min 20 min reported by a user
b LX 209 sec 195 sec my actual timing
c LX 87 sec 80 sec after making named pipe local
d LX 3 sec 3 sec outside the boundary (graphics clipped)
e Sparc 2 10 sec 10 sec w/ graphics run remotely,
running SunOS 4.1.1
This speedup for (c) was obtained simply by making the named pipes for
the graphics on a local disk instead of an NFS-mounted disk (changing
path in monitorcap). The speedup for (d) shows just how much time
the graphics requires (since I did the digitizing outside of the current
viewport). The timings for the Sparc2 (e) were done remotely using the same
digitizer/source code. We just ran a serial line from one room to another,
connecting the digitizer to the Sparc 2, and I ran grass4.1 and v.digit2
on the Sparc 2 while using the LX's console.
For this last one, the named pipes were not local, so we had:
______ _______
|server|------|sparc 2|
------ / -------
| / |
__|___ / ____|_____
| LX |--| |--|digitizer|
------ ----------
all disks on server (4.1.3), including named pipes, database, & binaries
grass/v.digit running on sparc 2's cpu
using the LXs display
Granted, some of these results are due to the speed/traffic level
on our local network, but I think that they adequately reflect
performance on a normal day (e.g, for a "heavy traffic" day, see
the results for (a)).
Conclusions: The current method of doing graphics (through named pipes)
is the reason for the significant slow-down under Solaris 2 - apparently
this scheme does not function nearly as fast under this OS. Significant
savings may be made by putting the named pipes on a local disk, but
this does not get us to the performance of the Sparc 2.
Sorts of begs for a *true* XDRIVER (no named pipes),
but who will fund this work?
--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) ***