From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id B18BB26B48 for ; Sun, 19 May 2024 03:04:48 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 44B1443677; Sun, 19 May 2024 11:04:42 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1716080682; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=Vf0spdkqN2MaoJQ3g0+JZaXYXOYdf+XUO39l10Zdk50=; b=LUa/4oysyyno1ubmN2Q056ihthjEt3MKwXggs0hSsER3UgftvML/07OWV76ciZDRZ2s82W 6wyQhxT24BW7IfTeFxHlw+jGCwU+Zft+iGLuF8OfJ7p6gTC2DPNxzvQojfouRYNb+7HJfA mXajBDvgPwzuG9NbfAbvockauERAPPY= Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by minnie.tuhs.org (Postfix) with ESMTPS id C33BC43672 for ; Sun, 19 May 2024 11:04:36 +1000 (AEST) Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1ee42b97b32so45854495ad.2 for ; Sat, 18 May 2024 18:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1716080676; x=1716685476; darn=tuhs.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Vf0spdkqN2MaoJQ3g0+JZaXYXOYdf+XUO39l10Zdk50=; b=0E5UBoYw55Pzje6y1eHqkii7MfdYzayLn4IU4SJfnfQn4+HN/FDFnB+XXAe+MwNk2L dq7pVE3L/gEvgjS1GTjdKlJN7Siaamz/KS5rVQER01wLITQA7Q4UrBEwqaiTuTHSQiEG YRqliALUBc5SpXeqVoeQidZuJwOV+eFNhysCgR9G89uXxVGvCxh/kixr042LiqDRfrp7 wd5Fkdz78x8T2ZbWyFz7iJ1kn+O6BIYxDvvEjjJXnnlz/0pPLscV8uANXqEL/JlGP46C PCcx/WSJwE9BWYaSq6deaEWcTWbSGzweBphthiuZIs6bqLImsRcBqIbMgVZdT0g6IB1g j9Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716080676; x=1716685476; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Vf0spdkqN2MaoJQ3g0+JZaXYXOYdf+XUO39l10Zdk50=; b=Dz/XDOlmV0zEhuXnwe5JUT9sRS3f7tOic3qQ+i2kddDd99k9gIv5Qip7ue330f3xtI tBnkP8jj2zrmeT2JYaBitdP5VK+LcDlqM/AWZ0c+33qyBXgjBo0luptP6GjwGY5H3I1/ Vpb+ibtR4U+OSo2RyBIILQVIwcwVLTXe+QcM37WXgFYo9Qp0weBSDKpjkpYosleOd0hc 4bIWyMlyENGhWqxUZe4mx6TVM4YVwnPAmZWzV80iOKYzU0Vco6+xwuqNZhAn9wMiaPE2 c19ahKQ+j3HxYRauIP7WkzEagvinNMM/AB6jWrtljs15LCkZ7bCjvUNodyFWK/FeysaU NhPQ== X-Forwarded-Encrypted: i=1; AJvYcCUMvLZARDdAKZnx1ZrqmfIG7tY4OPdmUPe2wRuZWpzyWlt5Jwtv4sqcRb93RtwoJEyPfQf8Exo/PfgKlvB3 X-Gm-Message-State: AOJu0YxO6aASnCSWTGyPkOjuTal0JuSykABHh5CBLe4ycGgd12TyU46C 6sWtWbnOXrCDO4BPtW2Q52ToO+FF8uvo1QSAvcTfTMCjIw6E0fwhInk3LLfEJGMrMFlUDwzIMv8 = X-Google-Smtp-Source: AGHT+IEYKVRXqaZlCgsAg4gh/AvB0Eb149OMyIgphMDxn2IkJPXZfkaJH01vz39YV/XbkraZ5HLPgA== X-Received: by 2002:a17:902:e809:b0:1f2:f962:8d3 with SMTP id d9443c01a7336-1f2f9620e33mr6116635ad.1.1716080675796; Sat, 18 May 2024 18:04:35 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0c1364ecsm178968555ad.248.2024.05.18.18.04.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 May 2024 18:04:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) In-Reply-To: <20240515164212.beswgy4h2nwvbdck@illithid> Date: Sat, 18 May 2024 18:04:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8D556958-0C7F-43F3-8694-D7391E9D89DA@iitbombay.org> References: <20240514111032.2kotrrjjv772h5f4@illithid> <20240515164212.beswgy4h2nwvbdck@illithid> To: "G. Branden Robinson" X-Mailer: Apple Mail (2.3774.600.62) Message-ID-Hash: JXJK53DRR4DJA2Q3MVYIZ2JBDZKLVKPA X-Message-ID-Hash: JXJK53DRR4DJA2Q3MVYIZ2JBDZKLVKPA X-MailFrom: bakul@iitbombay.org 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: The Unix Heritage Society mailing list X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: If forking is bad, how about buffering? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Bakul Shah via TUHS Reply-To: Bakul Shah X-Spam: Yes On May 15, 2024, at 9:42=E2=80=AFAM, G. Branden Robinson = wrote: >=20 > I contemplated following up Bakul Shah's > post with a mention of Jim Gettys's work on bufferbloat.[1] So let me > do that here, and venture the opinion that a "buffer" as popularly > conceived and implemented (more or less just a hunk of memory to house > data) is too damn dumb a data structure for many of the uses to which = it > is put. Note that even if you remove every RAM buffer between the two endpoints of a TCP connection, you still have a "buffer". Example: If you have a 1Gbps pipe between SF & NYC, the pipe itself can store something like 3.5MB to 4MB in each direction! As the pipe can be lossy, you have to buffer up N (=3Dbandwidth*latency) bytes at the sending end (until you see an ack for the previous Nth byte), if you want to utilize the full bandwidth. Now what happens if the sender program exits right after sending the last byte? Something on behalf of the sender has to buffer up and stick around to complete the TCP dance. Even if the sender is cat -u, the kernel or a network daemon process atop a microkernel has to buffer this data[1]. Unfortunately you can't abolish latency! But where to put buffers is certainly an engineering choice that can impact compositionality or other problems such as bufferbloat. [1] This brings up a separate point: in a microkernel even a simple thing like "foo | bar" would require a third process - a "pipe service", to buffer up the output of foo! You may have reduced the overhead of individual syscalls but you will have more of cross-domain calls!=