From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12892 invoked from network); 12 Aug 2023 05:08:33 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 12 Aug 2023 05:08:33 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7890440BDF; Sat, 12 Aug 2023 15:08:25 +1000 (AEST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by minnie.tuhs.org (Postfix) with ESMTPS id 67BF040BCF for ; Sat, 12 Aug 2023 15:08:14 +1000 (AEST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5234f46c6f9so3420608a12.3 for ; Fri, 11 Aug 2023 22:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691816892; x=1692421692; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1n5xiRZ++ZiXx8JfvSECdYd6zkOMkMbwKMY9jAT7pfU=; b=sHs0hQnnkurp3i9E7WnveFygzQGPcC5nj3wFLkQRSKLzvOkmTeGtoS8GEolz0UX2gX mhskh9pV43U7IY/+93vJ/cCbWES7VNSGWpK0l5rmvK8/8JJJvqAw5LRLjx3Oc9Am07Pu zSSUmrWMyXDhqjFgL0yPQWFtUeKrx0SzrEQ8LpnerR0RNfp3PH+kHrNKuRrVPCZ1Zseb 1e7pl6aStZdVkO2w9dlMcxkm4c0SVDGmlyr4DZ09Es9NMG0Y8K49PavorpwCUZMkeXxW YjZ48nD37RjWcgwPekPd+sjYzqAyymlx4pQDns7e6qdGGDIT+EVruzQFHa7C0ULSknfH HSbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691816892; x=1692421692; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1n5xiRZ++ZiXx8JfvSECdYd6zkOMkMbwKMY9jAT7pfU=; b=QcTc4JKIaf3TmMkSJAKwM9SMVU+GO9ln6LPKYBntbNRYtPv+NNi4DljyixDVqTzPD7 S0iGntO4CTqyvjOwKiz7u5ixgXSt0dAJz1Hl2Z8hlydcLEGYUNeXZGmGEDJEpmvxc0qR Bad1NH6EJQWH4E3r9F0k9q33ECnz8LGl1RQ+qZDYZGhs2kO116NNgOwN8pHm8EX1uGE2 aPiVwPT/ukN9cHpDxLWSjKgCdMv7HK9lS3unsi7AIqcConFEX8ooZWwmj2+kkfIvCMR4 2zAvvUG4NfYj4O8Ih1h+1oKXk0nHJUnzt32qkfIkaxq2IeJ0qymuXpAZXeGS6L9Oz9qb e7BQ== X-Gm-Message-State: AOJu0YxRPjdMBq+TlxQMs3mha/skSTnNwo2LwHqi5IAnLl4rASP96zcs ehDO2HOUo1mPwPwpAZnfuXEGnO/xQPJOr2y+Sx8LoA== X-Google-Smtp-Source: AGHT+IEgR99sshFJU/uw0vcxfooj0hw5sbMGsbKVIEfqxkbpdQDn6S7n3POSngh/XqwdR3L3O1+yGJY2mGrfDFQBbaM= X-Received: by 2002:aa7:cc0e:0:b0:523:48d7:70b1 with SMTP id q14-20020aa7cc0e000000b0052348d770b1mr3067946edt.19.1691816891890; Fri, 11 Aug 2023 22:08:11 -0700 (PDT) MIME-Version: 1.0 References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> In-Reply-To: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> From: Warner Losh Date: Fri, 11 Aug 2023 23:08:00 -0600 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="000000000000ddd2330602b2d092" Message-ID-Hash: TLVWRL2CTHABYFV3M7RANMPP54IKXPU7 X-Message-ID-Hash: TLVWRL2CTHABYFV3M7RANMPP54IKXPU7 X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: when did v8 or later get networking? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ddd2330602b2d092 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2023 at 3:05=E2=80=AFAM Paul Ruizendaal wro= te: > Bill Joy of CSRG concluded that the BBN stack did not perform according t= o > his expectations. Note that CSRG was focused on usage over (thick) ethern= et > 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 wa= s > written from scratch using the spec versus it being mostly copied. Lookin= g > 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 retain= ed > the =E2=80=98mbuf=E2=80=99 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. Warner --000000000000ddd2330602b2d092 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 11, 2023 at 3:05=E2=80=AF= AM Paul Ruizendaal <pnr@planet.nl&g= t; wrote:
Bill J= oy of CSRG concluded that the BBN stack did not perform according to his ex= pectations. Note that CSRG was focused on usage over (thick) ethernet links= , and BBN was focused on usage over Arpanet and other wide-area networks (w= ith much lower bandwidth, and higher latency and error rates). He then in 1= 982 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 usi= ng the spec versus it being mostly copied. Looking at it with a nearly 50 y= ear distance, it seems in between: small bits of surviving SCCS suggest CSR= G starting with parts of BBN code followed by rapid, massive modification; = the end result is quite different but retained the =E2=80=98mbuf=E2=80=99 c= ore data structure and a BBN bug (off-by-one for OOB TCP segments).

When Kirk McKusick tells=C2=A0 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 perfo= rmed terribly (multiple seconds to connect sometimes, single digit kB over = 10Mb media, etc). He optimized it to make it perform well. This was a combi= nation of rewriting chunks and tweaking other chunks, which matches your an= alysis of SCCS. When BBN came back with their new, release ready stack Bill= supposedly said something like 'no thanks, we already got one that wor= ks way better.' This is why much of the structure of the original BBN s= tack survived the rewrite: if there wasn't a big issue with them, the d= esign and mechanisms wound up being conserved by this effort. It was too mu= ch 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 histor= y retrospective talks to differing degrees. Sorry I don't have an exact= reference.

Warner
--000000000000ddd2330602b2d092--