Is SpaceX overvalued?

[Robotbeat]

SpaceX has to regularly sell stock to allow employees, who receive stock options as part of their compensation, to cash out. This is where headline valuations come from. It’s not part of the public stock market, you have to be an “accredited investor” to have even a shot at buying stock in SpaceX.

[Robotbeat]

Starlink could easily get to a similar revenue level as Comcast. (And yes, SpaceX could bundle TV, etc, like other cable or satellite providers.)

Unless you are separating the telecom portion out from those numbers please be aware the Comcast owns NBC Universal. So as a whole company they are a cable provider, streaming service, production company, theme park operator, etc...

That’s a very good point, but they still get most of their revenue from the telecom side.

[dondar]

I'm actually quite surprised at the subscriber growth. It's almost 100k/month now.

"Exponential growth" is a fantasy in the real world. If you want to estimate future market you have to look for the uncovered market. There is considerate incoming market in south East Asia (Indonesia, Tailand, Vietnam where the major clients will be local goverments), South America and US. The growth beyond 500k is bound by the proper development of inter-sat links (software is a prime target, I am extremely curious how they will solve routing paths) and proper bandwidth-ed ground stations (apparently SpaceX has some issues in some areas of US already). Basically yet another year to wait for the proper Starlink growth.

The two issues are related. You need ISL to shift the teleport traffic away from the congested teleports.

No in-space routing at the IP layer. Use frame forwarding at the frame layer using a specialized frame layer. Because ISL topology changes are known in advance table updates are not reactive. Instead, forwarding tables have scheduled updates what change with microsecond precision. Similarly, the user terminals switch between beams in a precisely-timed fashion, as do teleport-satellite links: all of this is handled by the specialized frame layer and its forwarding tables.  I never worked for SpaceX so I do not know that they are doing it this way, but I did do a preliminary system design as part of a business proposal for a different constellation in 2014.

laser Inter-sat links==mult-node dynamic relay network. At the scale of Starlink they will end with semi-distributed model. You need to do dynamic allocation.

[DanClemmensen]

I'm actually quite surprised at the subscriber growth. It's almost 100k/month now.

"Exponential growth" is a fantasy in the real world. If you want to estimate future market you have to look for the uncovered market. There is considerate incoming market in south East Asia (Indonesia, Tailand, Vietnam where the major clients will be local goverments), South America and US. The growth beyond 500k is bound by the proper development of inter-sat links (software is a prime target, I am extremely curious how they will solve routing paths) and proper bandwidth-ed ground stations (apparently SpaceX has some issues in some areas of US already). Basically yet another year to wait for the proper Starlink growth.

The two issues are related. You need ISL to shift the teleport traffic away from the congested teleports.

No in-space routing at the IP layer. Use frame forwarding at the frame layer using a specialized frame layer. Because ISL topology changes are known in advance table updates are not reactive. Instead, forwarding tables have scheduled updates what change with microsecond precision. Similarly, the user terminals switch between beams in a precisely-timed fashion, as do teleport-satellite links: all of this is handled by the specialized frame layer and its forwarding tables.  I never worked for SpaceX so I do not know that they are doing it this way, but I did do a preliminary system design as part of a business proposal for a different constellation in 2014.

laser Inter-sat links==mult-node dynamic relay network. At the scale of Starlink they will end with semi-distributed model. You need to do dynamic allocation.

I worked with a bunch of very experienced system architects with many collective years of experience in networking, and I learned that it was a common (nearly universal) tendency to try to apply existing network models to the satellite constellation problem. Basically, these models fail in this environment. The constellation topology is indeed highly dynamic: generally several orders of magnitude more setup/teardown events than in terrestrial networks. However, except for a tiny percentage of them the topology changes are also absolutely predictable down to the microsecond. An appropriate specialized frame layer can support this dynamic topology without the need to signal each topology change. Of course you must signal changes caused by failures, restorals, and new satellites. Yes, you need dynamic bandwidth allocation, at least on the RF links (user beams and teleport beams). You may or may not need to consider bandwidth constraints on the ISL. Yes this allocation must be distributed or the system won't scale, but it may or may not be distributed to the teleports or to PoPs on the ground instead of the satellites.