From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9696F3B29D for ; Sat, 5 Mar 2022 05:10:14 -0500 (EST) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 57FF71248E9; Sat, 5 Mar 2022 02:10:13 -0800 (PST) Date: Sat, 5 Mar 2022 02:10:13 -0800 (PST) From: David Lang To: Ulrich Speidel cc: dickroy@alum.mit.edu, 'David Lang' , starlink@lists.bufferbloat.net In-Reply-To: Message-ID: <966qn2p2-n0s2-s9np-pos6-3sr3qs3r7o80@ynat.uz> References: <1646351242.121623495@apps.rackspace.com> <2b2f1808-8cf7-6eae-3157-a5fc554a2424@auckland.ac.nz> <03e73122-63c3-497b-82c6-b7b7f23b627a@Spark> <3ooo342q-s937-qq3-492q-723np793qoo@ynat.uz> <7ee92a7f-ae58-5090-8ee0-32df8ec29c2b@auckland.ac.nz> <712r509p-7on6-5657-3172-n9140n9097@ynat.uz> <2a03ec91-d938-1c85-ae0d-1cd23536f497@auckland.ac.nz> <2DA12D3D736443699EBFD93FDC9325A2@SRA6> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="228850167-395655857-1646475013=:60202" Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue 6 X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2022 10:10:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --228850167-395655857-1646475013=:60202 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Sat, 5 Mar 2022, Ulrich Speidel wrote: > On 5/03/2022 7:38 pm, Dick Roy wrote: >> >> */[RR] But they are assuming a “single” channel in the time domain.  When >> you can take advantage of other dimensions (eg. space) to create more >> channels, (aka SDMA) the capacity goes up!/* >> > /*Taken as read - but it's beside the point. Shannon-Hartley allows you to do > what was proposed - turning a channel that supplies a small number of users > with a lot of capacity each into one that supplies a large number of users > with a little capacity each, and of course if you add diversity (space, > polarisation, ...) then this applies even more so. But the point is that each > communication system is designed around an expectation of how many users will > access it, and that you can't simply take an existing technology and somehow > assume that it will work with a larger number of users just because it's > theoretically possible. Basically, you can't simply throw more dishys at the > problem if you need to serve more users.*/ I don't think anyone is suggesting throwing a massive number of dishys at the problem, instead I'm saying that one dishy can support a rather larger number of people than one household (with appropriate app selection) Up until about a year ago, the best that I could get at my house was a 8/1 pair of bonded DSL lines (supposed to be a 10/2, but reliability). That actually supported 3 people watching videos plus a mail server and various downloading (and one of the video watching was commonly replaced by video meetings). I did try to avoid large downloads during meetings :-) Currently I have the 8/1 DSL and a 600MB cable (and haven't yet integrated starlink), but I don't always notice when the cable goes out right away (without doing something extremely bandwidth heavy), although if it drops to 4/.5 (cable and one DSL down), it's pretty noticable. people who are used to multi hundred Mb or Gb lines don't realize that a lot of the stuff they use (outside of bulk downloads) isn't really using that much bandwidth (insert bufferbloat rant here :-) ) David Lang --228850167-395655857-1646475013=:60202--