12 Apr
2020
12 Apr
'20
10:03 a.m.
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:
It was streams, not STREAMS.
-- 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? 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.
12 Apr
12 Apr
10:55 p.m.
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(a)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(a)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:
It was streams, not STREAMS.
-- 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? 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.
14 Apr
14 Apr
2:54 p.m.
joe mcguckin <joe(a)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(a)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.
12 Apr
12 Apr
11:15 p.m.
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
13 Apr
13 Apr
1:43 a.m.
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(a)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
3 a.m.
Rob Pike <robpike(a)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/13601b6f49db83aa369e382f5242927a46d2a4…
2.
https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a4…
3.
https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a4…
4.
https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a4…
3:14 a.m.
Nice to see Egreg again.
-rob
On Mon, Apr 13, 2020 at 1:00 PM Anthony Martin <ality(a)pbrane.org> wrote:
Rob Pike <robpike(a)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/13601b6f49db83aa369e382f5242927a46d2a4…
2.
https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a4…
3.
https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a4…
4.
https://github.com/0intro/9hist/blob/13601b6f49db83aa369e382f5242927a46d2a4…
1472
days inactive
1474
days old
6 comments
5 participants
participants (5)
-
Anthony Martin -
joe mcguckin -
Paul Ruizendaal -
Rob Pike -
Tony Finch