Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Vint Cerf <vint@google.com>
To: Bruce Perens <bruce@perens.com>
Cc: Dave Taht <dave.taht@gmail.com>,
	 Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] risc-v in space
Date: Tue, 6 Sep 2022 18:41:58 -0400	[thread overview]
Message-ID: <CAHxHggc8JHEG4ioVifms555uW3zMNzaybpvA-M9h0=KeT7jmQQ@mail.gmail.com> (raw)
In-Reply-To: <CAK2MWOvAZKr0JnLaKHOZra-DKx8r-WyXJ9miYoJXTY1BbE3=Kw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3119 bytes --]

ok to share with non-list colleagues?

v


On Tue, Sep 6, 2022 at 3:51 PM Bruce Perens via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
>
>> The larger question I have though, is how much do we know now about
>> rad-hardening electronics in space?
>>
> I've learned some.
>
> Not quite related to that, but if you want to run an Open Source Space
> project in the US without running afoul of ITAR and EAR, I can tell you
> how. The policy I created was approved by Department of State and
> Department of Commerce.
>
> Here is a simple explanation for the uninitiated:
>
> This is less severe for LEO because the satellites don't traverse the van
> Allen belts. But the coronal mass ejections we are having just now and
> their associated electrical effects could make the situation worse whatever
> orbit you are in.
>
> The largest problem we have is that radiation can trigger a junction to
> conduct. If you have built your chip on a semiconductor substrate, that
> means that some random chip feature can start conducting to the substrate
> and latch that way until power is removed. Overcurrent can blow details
> right off of the chip. So, you must build your chip on an insulating
> substrate. This used to be silicon on sapphire, which was incredibly
> expensive. Silicon on insulator does the job. It happens that many common
> FPGAs are built on insulator, so that is a cheap way to get space-robust
> processing.
>
> Second issue is that you can get random triggering of junctions. This
> means that chips can do the unexpected, and you need redundancy on-chip or
> off, and a way to power off the chip because sometimes nothing else will
> reset it. You also need error-correction on your memory, and a process that
> continually "washes" your memory by reading it, and writing the corrected
> data.
>
> It doesn't work to shield your electronics with some dense material like
> lead. The problem is that a high-energy particle can hit that and turn into
> lots of lower-energy particles that are actually more harmful. So, a thick
> enough shield to stop all of these secondary emissions is usually not
> practical.
>
> If you have enough money, you can pay a company like Vorago for a
> space-qualified processor. It's pin-compatible with a non-space version of
> the same CPU, so you can test it cheaply.
>
> and of course we see astronauts using COTS laptops.
>
>
> Those laptops aren't mission-critical. The risk to the astronauts is
> probably a worse problem, for missions that traverse the van Allen belts.
> Apollo used the location of a low-energy region, and got through there
> quickly. Interplanetary missions are probably going to require lots of
> water around the place where the people stay when there's a solar flare.
>
>     Thanks
>
>     Bruce
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 4482 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3995 bytes --]

  reply	other threads:[~2022-09-06 22:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 19:19 Dave Taht
2022-09-06 19:51 ` Bruce Perens
2022-09-06 22:41   ` Vint Cerf [this message]
2022-09-07  4:30 ` Bruce Perens

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='CAHxHggc8JHEG4ioVifms555uW3zMNzaybpvA-M9h0=KeT7jmQQ@mail.gmail.com' \
    --to=vint@google.com \
    --cc=bruce@perens.com \
    --cc=dave.taht@gmail.com \
    --cc=starlink@lists.bufferbloat.net \
    /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