[TUHS] STREAMS performance

[TUHS] STREAMS performance

[Paul Ruizendaal]

> Date: Sat, 11 Apr 2020 08:44:28 -0700
> From: Larry McVoy
> 
> On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote:
>> -- Stream I/O system added; all communication-device
>> drivers (serial ports, Ethernet, Datakit) changed to
>> work with streams.  Pipes were streams.
> 
> How was performance?  Was this Dennis' streams, not Sys V STREAMS?

It was streams, not STREAMS.

> I ported Lachmans/Convergents STREAMS based TCP/IP stack to the
> ETA 10 Unix and SCO Unix and performance just sucked.  Ditto for
> the Solaris port (which I did not do, I don't think it made any
> difference who did the port though).

STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued.

What in the above case drove/caused the poor performance?

There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself.

Did STREAMS also perform poorly in the 1986 context they were developed in?

Paul

*) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate.

Re: [TUHS] STREAMS performance

[joe mcguckin]

I seem to remember that Sun was trying to sell boxes to the airline / reservation industry, and one of the ways they came up with
to make Solaris handle thousands of ascii terminals was to push the character discipline code into streams in order to eliminate the multiple user/kernel
crossings per character being handled…

Joe


Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Apr 12, 2020, at 3:03 AM, Paul Ruizendaal <pnr@planet.nl> wrote:
> 
> 
>> Date: Sat, 11 Apr 2020 08:44:28 -0700
>> From: Larry McVoy
>> 
>> On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote:
>>> -- Stream I/O system added; all communication-device
>>> drivers (serial ports, Ethernet, Datakit) changed to
>>> work with streams.  Pipes were streams.
>> 
>> How was performance?  Was this Dennis' streams, not Sys V STREAMS?
> 
> It was streams, not STREAMS.
> 
>> I ported Lachmans/Convergents STREAMS based TCP/IP stack to the
>> ETA 10 Unix and SCO Unix and performance just sucked.  Ditto for
>> the Solaris port (which I did not do, I don't think it made any
>> difference who did the port though).
> 
> STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued.
> 
> What in the above case drove/caused the poor performance?
> 
> There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself.
> 
> Did STREAMS also perform poorly in the 1986 context they were developed in?
> 
> Paul
> 
> *) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate.
> 

Re: [TUHS] STREAMS performance

[Tony Finch]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

joe mcguckin <joe@via.net> wrote:
>
> I seem to remember that Sun was trying to sell boxes to the airline /
> reservation industry, and one of the ways they came up with to make
> Solaris handle thousands of ascii terminals was to push the character
> discipline code into streams in order to eliminate the multiple
> user/kernel crossings per character being handled…

I encountered this feature when deploying some new Solaris 2.5.1 / 2.6 web
servers in about 1997/8. We were chroot()ing the user login daemons
(telnet and ftp) to improve security, and they wouldn't work on a freshly
rebooted server. Eventually I worked out that telnetd loaded a kernel
module on demand, and this didn't work when it was chroot()ed, but telnetd
could skip it if the module had previously been loaded. (I could see from
truss and/or strings that telnetd was specifying an absolute path to the
module rather than expecting the kernel to know where to find it.) I was
kind of impressed by the performance engineering, and it stuck in my
memory because it took me so long to understand why it sometimes didn't
work...

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Trafalgar: Variable 3 or 4 at first in southeast, otherwise cyclonic 5 to 7.
Moderate or rough, occasionally very rough at first in northwest. Rain or
thundery showers. Good, occasionally poor.

Re: [TUHS] STREAMS performance

[Anthony Martin]

As an aside, Plan 9 began with a descendant of dmr's streams
but replaced it in mid-1993 with a simple queued i/o scheme.
This was done for performance and to simplify the code since
they didn't end up using much of the streams functionality.

  Anthony

Re: [TUHS] STREAMS performance

[Rob Pike]

It did? I think a version of streams showed up at some point, and were
replaced; of that you are correct. But it certainly didn't begin with
anything like streams. It began with a file system mux.

-rob

On Mon, Apr 13, 2020 at 9:16 AM Anthony Martin <ality@pbrane.org> wrote:
>
> As an aside, Plan 9 began with a descendant of dmr's streams
> but replaced it in mid-1993 with a simple queued i/o scheme.
> This was done for performance and to simplify the code since
> they didn't end up using much of the streams functionality.
>
>   Anthony

Re: [TUHS] STREAMS performance

[Anthony Martin]

Rob Pike <robpike@gmail.com> once said:
> It did? I think a version of streams showed up at some point, and were
> replaced; of that you are correct. But it certainly didn't begin with
> anything like streams. It began with a file system mux.

I realize you would probably know better, but ...

I didn't mean that streams was the first thing in Plan 9, just that the
I/O system for pipes, network devices, etc. was descended from streams.
That was the case at least as far back as 1990.

Look at the early Plan 9 code for the pipe¹ and ethernet² devices, the
code for Streams, Queues, and Blocks in port/stream.c³ and power/dat.h⁴,
and tell me that doesn't descend from v8 streams. :)

Also, thanks for Plan 9. It's lovely.

  Anthony

1. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devpipe.c
2. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devlance.c#L256
3. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/stream.c
4. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/power/dat.h#L338

Re: [TUHS] STREAMS performance

[Rob Pike]

Nice to see Egreg again.

-rob

On Mon, Apr 13, 2020 at 1:00 PM Anthony Martin <ality@pbrane.org> wrote:
>
> Rob Pike <robpike@gmail.com> once said:
> > It did? I think a version of streams showed up at some point, and were
> > replaced; of that you are correct. But it certainly didn't begin with
> > anything like streams. It began with a file system mux.
>
> I realize you would probably know better, but ...
>
> I didn't mean that streams was the first thing in Plan 9, just that the
> I/O system for pipes, network devices, etc. was descended from streams.
> That was the case at least as far back as 1990.
>
> Look at the early Plan 9 code for the pipe¹ and ethernet² devices, the
> code for Streams, Queues, and Blocks in port/stream.c³ and power/dat.h⁴,
> and tell me that doesn't descend from v8 streams. :)
>
> Also, thanks for Plan 9. It's lovely.
>
>   Anthony
>
> 1. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devpipe.c
> 2. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/devlance.c#L256
> 3. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/port/stream.c
> 4. https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a433/power/dat.h#L338