Xref: utzoo comp.unix.i386:3507 comp.sys.intel:1175
Path: utzoo!attcan!uunet!seismo!ukma!xanth!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!philapd!ssp2!pb
From: pb@idca.tds.PHILIPS.nl (Peter Brouwer)
Newsgroups: comp.unix.i386,comp.sys.intel
Subject: Re: Tuning Streams
Message-ID: <595@ssp2.idca.tds.philips.nl>
Date: 13 Mar 90 11:56:58 GMT
Reply-To: pb@idca.tds.philips.nl (Peter Brouwer)
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 24
Summary:
Expires:
References:<4Y62V32xds13@ficc.uu.net>
Sender:
Followup-To:
Organisation: Philips Information Systems, Apeldoorn, The Netherlands
Disclamer: This is mine opinion alone.
Keywords:


 In article <4Y62V32xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>We're experiencing some problems with a network implementation on an intel
>320 running System V/386. The performance is dog slow, and we suspect that
>the fact that it goes through streams may have something to do with it. Has
>anyone any suggestions for how to go about tuning the system to optimise
>streams throughput?

Yes , you are at the right place to suspect streams. But actually its not 
streams but the spl calls that are initiated byt eh streams library functions.

We have the experience that the overhead might vary between 8 till 30%.
It depends on the stream modules used. For streams tty its ca. 10%
In one case we measured an overhead of 30%. This was a dc testprogram 
generating a 100% cpu load, 30% of that was due to spl calls. The big
spender is the function that changes the interrupt level in the PIC chip.

There is nothing to tune for this . The thing to do is to check the source
code in the use of streams calls . 
-- 
Peter Brouwer,                # Philips Telecommunications and Data Systems,
NET  : pb@idca.tds.philips.nl # Department SSP-P9000 Building V2,
UUCP : ....!mcvax!philapd!pb  # P.O.Box 245, 7300AE Apeldoorn, The Netherlands.
PHONE:ext [+31] [0]55 432523, #