<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Heya,<br />
<br />
My 2 cents - I have some experience with ground-based FSOC links, so I can take educated guesses at what they may be able to achieve.<br />
<br />
The laser links, as far as I know, will be able to do in-plane and cross-plane (e.g. between satellites in front and behind in the orbit, or across to the sides). This gives a great level of flexibility, but also complicates the system as you now need a rotating head or full gimbal. <br />
<br />
Ground-based FSOC links have a scan time that can range from a few seconds to a few minutes, depending on how long a link has been lost, and they all must begin with a fairly accurate idea of where you are pointed. Setting up a link to a satellite that is more or less static, in front or behind, is relatively easy. If you link is lost, you can re-establish fairly quickly.<br />
<br />
Across planes on the same shell, the positions are almost static too, so the same rules apply. From photos, each satellite carries two optical heads, thus IMHO the first generation will link in-plane only, to keep things simple. To do both in-plane and cross-plane, you need at least three optical heads.<br />
<br />
Once you add more shells, the problems begin. Optical links work in microradians (0.0000572º, your brain needs to adapt to these new scales…), so when satellites across planes could have relative velocities in the degrees per second, a laser link will have a real hard time to scan for the other site.<br />
<br />
I could bore you to death but here’s a quick test you can do: grab a laser pointer and try to keep it on a target the size of the laser dot on a wall 10-15 meters away. You’ll quickly see why doing that at hundreds of kilometers, and between moving vehicles, is a real challenge.<br />
<br />
The logical thing to start with would be to keep every shell interconnected, but not to try to cross-link shells. For this, ground-to-satellite links come into play.<br />
<br />
How do you make capacities in the petabits per second around your space segment useful? You need to deliver to the ground eventually. IMHO the only way this will hapen is ground-to-satellite links, with the ground stations either in a few, as cloudless as possible locations, or many stations in as geographically diverse configuration as possible, so that at least some will not have cloud cover.<br />
<br />
Once you have the ground links to each shell, they can be used to offload to internet backbones, or you can relay data between shells, without complicating your pointing & tracking on the satellites.<br />
<br />
I think Dave has a point in that a very obvious use is HFT and the like, as the latencies will be way way lower than what you could achieve with ground fiber.<br />
<br />
Mark Handley makes a very good job at explaining in this video (and others he has posted): <a href="https://www.youtube.com/watch?v=QEIUdMiColU" target="_blank">https://www.youtube.com/watch?v=QEIUdMiColU</a></div>
</div>
<div name="messageSignatureSection"><br />
<div class="matchFont">Best,<br />
<br />
Mike</div>
</div>
<div name="messageReplySection">On Oct 26, 2021, 04:26 +0300, Dave Taht <dave.taht@gmail.com>, wrote:<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">I haven't really been focused on the starlink stuff for many months,<br />
although I do periodically run a test to see if they've fixed their<br />
bufferbloat anywhere. (nope). The networkQuality test from apple is<br />
now shipping in OSX!! and I can think about something else.<br />
<br />
I'd written this, I guess, over 2 years ago:<br />
https://www.reddit.com/r/Starlink/comments/brn6gg/will_starlink_have_bufferbloat/<br />
<br />
and had had a nice dialog with mark handley (who has since stopped<br />
writing anything about starlink so I kind of assume he went under NDA)<br />
<br />
At the time I first started thinking about this I had had a few<br />
objections to his simulations. One was that he made the assumption in<br />
his earliest simulations that the sats would be routing "up there"<br />
rather than down here. The first sats routed simply to the next hop or<br />
a failover hop and that is easy to think about (and the congestion<br />
problems soluble with the tools already developed by the bufferbloat<br />
project). His later sims did that, but neither set seemed to address<br />
congestion control issues.<br />
<br />
Now that the first laser sats are launching, thinking about how that<br />
would work, in the dearth of other information, is hard. One number I<br />
don't have is what the actual capacity is for each laser link<br />
(anyone?), and for how long. I'd also thought at the time I'd written<br />
the above that the value of going new york to tokyo primarily by<br />
satellite was a license to print money. The value of that path seemed<br />
to be in the millions/minute range - so I had generally assumed that<br />
usage of it would be governed by a virtual circuit setup, used<br />
internally, or by major governments, or investment houses. It made the<br />
most sense to me to terminate most links back to the ground as quickly<br />
as possible, otherwise.<br />
<br />
But in thinking about 33,000 sats... rather than the paltry (cough)<br />
few they've presently flown, as a giant LAG switch that can cross<br />
oceans, I can certainly see the concept being used for more general<br />
purpose traffic especially to the islands of the world. That gets me<br />
to my second question: of the field of view of the sat links?<br />
<br />
And then my humdinger question based on their launch schedule and<br />
satellite distribution... how long before they can get a first transit<br />
from new york (or london) to tokyo, borne entirely on the sat laser<br />
links themselves? It needn't be direct, just taking advantage of the<br />
known satellite laser links to get that far.<br />
<br />
<br />
--<br />
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw<br />
<br />
Dave Täht CEO, TekLibre, LLC<br />
_______________________________________________<br />
Starlink mailing list<br />
Starlink@lists.bufferbloat.net<br />
https://lists.bufferbloat.net/listinfo/starlink<br /></blockquote>
</div>
</body>
</html>