The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Warner Losh <>
To: Paul Ruizendaal <>
Cc: "" <>
Subject: [TUHS] Re: when did v8 or later get networking?
Date: Fri, 11 Aug 2023 23:08:00 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

On Fri, Aug 11, 2023 at 3:05 AM Paul Ruizendaal <> wrote:

> Bill Joy of CSRG concluded that the BBN stack did not perform according to
> his expectations. Note that CSRG was focused on usage over (thick) ethernet
> links, and BBN was focused on usage over Arpanet and other wide-area
> networks (with much lower bandwidth, and higher latency and error rates).
> He then in 1982 rewrote the stack to match the CSRG environment, changing
> the design to use software interrupts instead of a kernel thread and
> optimising the code (e.g. checksumming and fast code paths). It was a
> matter of debate how new the code was, with the extremes being that it was
> written from scratch using the spec versus it being mostly copied. Looking
> at it with a nearly 50 year distance, it seems in between: small bits of
> surviving SCCS suggest CSRG starting with parts of BBN code followed by
> rapid, massive modification; the end result is quite different but retained
> the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP
> segments).

When Kirk McKusick tells  the story, UCB got a beta release (or early
access) of the BBN stack. UCB was supposed to add the socket interface to
whatever was there. But Bill Joy found it performed terribly (multiple
seconds to connect sometimes, single digit kB over 10Mb media, etc). He
optimized it to make it perform well. This was a combination of rewriting
chunks and tweaking other chunks, which matches your analysis of SCCS. When
BBN came back with their new, release ready stack Bill supposedly said
something like 'no thanks, we already got one that works way better.' This
is why much of the structure of the original BBN stack survived the
rewrite: if there wasn't a big issue with them, the design and mechanisms
wound up being conserved by this effort. It was too much work to move from
mbuf to something else, and too little gain.

I tried to find a good link, but they are in his BSD history retrospective
talks to differing degrees. Sorry I don't have an exact reference.


[-- Attachment #2: Type: text/html, Size: 2433 bytes --]

  reply	other threads:[~2023-08-12  5:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11  9:05 Paul Ruizendaal
2023-08-12  5:08 ` Warner Losh [this message]
2023-08-12  5:41   ` George Michaelson
2023-08-12  9:06   ` Paul Ruizendaal
2023-08-12 10:29   ` Paul Ruizendaal
2023-08-12 15:20     ` Warner Losh
2023-08-12 15:24       ` Dan Cross
2023-08-12 16:12         ` Paul Ruizendaal
  -- strict thread matches above, loose matches on Subject: below --
2023-08-12 15:05 Noel Chiappa
2023-08-12 18:00 ` Paul Ruizendaal
2023-08-10  1:09 [TUHS] " Larry McVoy
2023-08-10  2:38 ` [TUHS] " segaloco via TUHS
2023-08-10  2:45   ` Warner Losh
2023-08-10  3:17     ` segaloco via TUHS
2023-08-10  3:18     ` Rob Pike
2023-08-10  5:44       ` John Cowan
2023-08-10 12:41 ` Douglas McIlroy
2023-08-10 14:00 ` Jonathan Gray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).