From: David Lang <david@lang.hm>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: dickroy@alum.mit.edu, 'David Lang' <david@lang.hm>,
starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue 6
Date: Sat, 5 Mar 2022 02:10:13 -0800 (PST) [thread overview]
Message-ID: <966qn2p2-n0s2-s9np-pos6-3sr3qs3r7o80@ynat.uz> (raw)
In-Reply-To: <c5a14d49-d20a-6821-e745-ca9f69b4b696@auckland.ac.nz>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
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
next prev parent reply other threads:[~2022-03-05 10:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1943.1646344903.1267.starlink@lists.bufferbloat.net>
2022-03-03 23:47 ` David P. Reed
2022-03-04 5:06 ` Ulrich Speidel
2022-03-04 7:00 ` Mike Puchol
2022-03-04 8:41 ` David Lang
2022-03-04 9:44 ` Ulrich Speidel
2022-03-04 17:07 ` Larry Press
2022-03-04 23:58 ` Ulrich Speidel
2022-03-04 17:08 ` Dave Täht
2022-03-04 17:10 ` Dave Taht
2022-03-04 18:14 ` David Lang
2022-03-04 18:21 ` Ben Greear
2022-03-04 18:30 ` David Lang
2022-03-05 0:14 ` Ulrich Speidel
2022-03-05 6:38 ` Dick Roy
2022-03-05 9:42 ` Ulrich Speidel
2022-03-05 10:10 ` David Lang [this message]
2022-03-05 18:26 ` Dick Roy
2022-03-05 15:25 ` Larry Press
2022-03-06 1:50 ` Ulrich Speidel
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=966qn2p2-n0s2-s9np-pos6-3sr3qs3r7o80@ynat.uz \
--to=david@lang.hm \
--cc=dickroy@alum.mit.edu \
--cc=starlink@lists.bufferbloat.net \
--cc=u.speidel@auckland.ac.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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