v.digit2/solaris 2

[Darrell McCauley]

[
 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 at 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 at ecn.purdue.edu West Lafayette, Indiana 47907-1146, USA
bitnet: mccauley%ecn at purccvm      UUCP: pur-ee!mccauley
*** avail. for full time employment 9/94-inquiries welcome (no hh, plz) ***