bkp_duke
Well-Known Member
It's not JUST the speed advantage. One of the MAJOR speed problems for current terrestrial-based fiber networks is switching. Everytime you go through a "hop", it adds significant latency.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
It's not JUST the speed advantage. One of the MAJOR speed problems for current terrestrial-based fiber networks is switching. Everytime you go through a "hop", it adds significant latency.
To add a few more data points:
Frontier (formerly Verizon) FiOS (Garland TX, nominally 80Mbit up/down):
ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=8.67 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=9.14 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=9.90 ms
Fontier (formerly Verizon) FiOS (Sachse TX, nominally... 300Mbit up/down? I don't remember):
ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=7.70 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=3.73 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=3.63 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=6.32 ms
Linode (this time from an instance in Dallas TX):
ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=0.988 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=121 time=1.05 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=121 time=1.07 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=121 time=1.05 ms
AT&T Dedicated Fiber (Plano TX, fiber to the office suite itself, split locally in our server room by an AT&T box to a capped 100Mbit data over 1Gbit ethernet interface to our router, plus a T1 to the PBX):
ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=2.67 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=2.55 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=2.54 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=2.53 ms
Also, I won't post the full traceroutes, but the two Frontier and the AT&T both were 9 hops and the Linode was 7 hops, for reference.
As a counterpoint anectdote showing that latency does matter to some extent (and a situation where even a single T1 would have been a blessing), many years ago before the cable providers had moved far enough up into the mountain to provide cable TV not to mention Internet, at my uncle's place at Lake Tahoe, they had DirecPC/HughesNet. This was when most people had dialup and not necessarily even '56k' dialup. It was marginally servicible if you didn't attempt to click through pages too quickly, and that only with a precaching proxy (would never work in today's SSL world) that was making requests to linked pages and assets on the page ahead of time before the browser did to reduce perceived latency. It was completely unserviceable for any kind of remote work (i.e. SSH) and of course gaming was right out. When I was there, I would opt to wait until I could hog the phone line and dial into my ISP at a much "slower" speed. While pages loaded faster, when they finally loaded, on the satellite connection, the wait time for anything to happen was maddening.
At various times in my life I've had access to most flavors of dialup, as well as a 56K leased line, dual channel ISDN, original ADSL where 1.5Mbps/128kbps theoretical performance was considered good for the price... I'd take any of those over the geosynchronous satellite delay. I'd be perfectly happy with the sort of response time Starlink seems to be giving from LEO. These days I sometimes do remote work that involves trans-atlantic SSH and by the time my packets get into the middle of Europe and then I see the response to my typing it can be quite irritating. Starlink's latency for day to day use will be fine, and if sat-to-sat links become a reality and they manage to route within Starlink as close to the destination as possible, it's very plausible that my trans-atlantic scenario would be much improved, though neither myself nor the site in the EU would be likely candidates otherwise as we both have local fiber service, so I'm unlikely to benefit unless Starlink starts doing backhaul for other ISPs.
Not to mention on the eco side, that when Starship becomes regularly operational, they are quite likely to make their own fuel by building a giant solar/battery (and possibly wind) farm and/or buying power that is generated in such a fashion, and then using the same methods to create methane and liquid oxygen as they would on Mars - both due to the scale of their needs making self generation of propellant ideal (most commercial production is geared towards a lower grade with more impurities, so the price and supply of what they want favors producing it themselves) as well as to endurance test a lot of the equipment (though it would be somewhat different for Mars applications, a lot can still be shared/learned). They can basically go "carbon neutral" on Starship (ignoring construction and such, which even then could in theory use green power), by capturing CO2 from the atmosphere to combine with H2O and make Methane + Liquid Oxygen. Of course technically it's not the same as they would be gathering from near ground in one area and then spreading it out over a larger higher altitude area, but even then the ecological impact of methalox launches (fewer weird secondary reactions) is going to be much less than traditional kerolox launches (lots of weird secondary reactions)
Cox -> Google isn't the best example here. I can confirm that Cox cable for whatever reason has significantly more latency to 8.8.8.8 than Spectrum (25 ms Cox vs 17 ms Spectrum), for example. Cloudflare's public DNS (1.1.1.1) has more consistent results across ISPs and datacenters for me.
Here is 1.1.1.1 on the same Cox 100/20 small biz HFC
ping -c4 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=25.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=24.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=26.1 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=23.6 ms
Path is almost identical
traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 192.168.12.1 (192.168.12.1) 0.183 ms 0.191 ms 0.202 ms
2 10.33.108.1 (10.33.108.1) 12.858 ms 12.799 ms 12.723 ms
3 100.127.77.6 (100.127.77.6) 13.611 ms 13.603 ms 13.634 ms
4 100.120.100.40 (100.120.100.40) 15.603 ms 15.539 ms 15.466 ms
5 langbprj01-ae1.rd.la.cox.net (68.1.1.13) 27.303 ms 27.291 ms 50.304 ms
6 141.101.72.254 (141.101.72.254) 27.019 ms 31.398 ms 31.368 ms
7 one.one.one.one (1.1.1.1) 25.036 ms 24.069 ms 24.039 ms
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.12.1 (192.168.12.1) 0.245 ms 0.228 ms 0.236 ms
2 10.33.108.1 (10.33.108.1) 10.992 ms 10.879 ms 10.744 ms
3 100.127.77.6 (100.127.77.6) 11.765 ms 11.731 ms 11.733 ms
4 100.120.100.40 (100.120.100.40) 13.429 ms 13.395 ms 13.427 ms
5 langbprj01-ae1.rd.la.cox.net (68.1.1.13) 25.360 ms 25.350 ms 68.1.4.254 (68.1.4.254) 25.452 ms
6 72.215.224.175 (72.215.224.175) 25.304 ms 72.14.196.240 (72.14.196.240) 24.837 ms 74.125.51.174 (74.125.51.174) 25.596 ms
7 * * *
8 dns.google (8.8.8.8) 24.911 ms 142.250.226.49 (142.250.226.49) 26.183 ms dns.google (8.8.8.8) 24.861 ms
Off Shore
Off Topic Member
Just unfollowed the thread, and I'd appreciate it if someone would let me know when it's useful to return. Thanks!
A separate thread was created to discuss Fibre versus Starlink. This thread should be about things happening with Starlink except the specific launches. Those have their own thread.
bkp_duke
Well-Known Member
Viasat asks FCC to perform environmental review of Starlink - SpaceNews
Can't beat em . . . cry to the Gov to step in . . .
Can't beat em . . . cry to the Gov to step in . . .
Geez, someone (cough, SpaceX, cough) should ask the FCC to investigate Viasat for deceptive marketing of its "service".
I'm not fan of Viasat but this should have been done before they started putting thousands of objects in orbit. As well as causing problems for astronomers there are questions that need answering about their ability to safely and cleanly de-orbit these things, and what happens when they fail.
Failures are a big issue. Say they have a 1% failure rate, that's hundreds of out-of-control satellites.
And even when they do de-orbit they don't just vanish, they burn up and as we know burning stuff isn't a great way to deal with rubbish.
Long time TMC member and Tesla proponent @bonnie is loving Starlink (over Century Link).
https://mobile.twitter.com/bonnienorman/status/1343955173048082432
Data point of one:
CL:
Starlink:
https://mobile.twitter.com/bonnienorman/status/1343955173048082432
Data point of one:
CL:
Starlink:
SpaceX has already de-orbited a number of satellites. If they fail, they will de-orbit no matter what. The satellites are at a low orbit that forces a de-orbit if left alone.
As for burning stuff up in the atmosphere, that is the only way it is done for anything in orbit. So to avoid that, other than what SpaceX is attempting to do with Starship, is to stop doing anything in space.
I live pretty close to her and have been crossing my fingers for entry into the beta. I have the same crappy CenturyLink dsl (except mine is even worse). I am a little concerned about the tree cover where I am but using the app I think I can get a clear view with about a 10' pole on my roof.
How many are signed up for the beta and just crossing your fingers everyday to be able to enter the world of adequate internet speeds?
There are ways to lessen the impact though. For example, the Japanese are working on wooden satellites:
Japan developing wooden satellites to cut space junk
That's the kind of innovation needed. Starlink will need tens of thousands of these things, don't forget. And they won't be the only ones up there.
Well, Geo Sats get boosted into a grave yard orbit, which arguably is even worse vs burning up in the upper atmosphere.
Japan is working on using wood for satellite construction to reduce the amount of metal particles that come from a de orbit burn up.
I think people vastly under estimate the "surface area" we are talking about here. The surface area of the earth is approximately 509,968,659 square kilometers. If you increase to the StarLink orbit of ~500KM, you get a surface area of approximately 593,266,000 square kilometers.
Dividing that across even the very long term 30,000 StarLink satellites, and put them all at the same orbital altitude, your still talking about one satellite per ~20,000 square kilometers. Your talking about one satellite per state of New Jersey basically, and that is at the 30,000 number. The initial constellation will be about 4,000 or about 1 per 148,000 square kilometers, or roughly the land mass of the state of Montana.
Overall people seem to think that StarLink is huge, and will "clutter up space" etc, which is an insane over reach. Additionally the vast majority of even hobbyist astro photographers have methods to remove StarLink digitally from their photos.
-Harry
This is VERY misleading math and not at all the way the space industry would asses a constellation. At high latitudes the satellites are bunched WAY together, the proximity of out-of-plane sats gets very close, and the number of conjunction events is mind boggling. At low latitudes the velocity deltas are at their extreme; conjunction events are on the order of km's/s. A low latitude collision will likely Kessler the whole shell in short order--for instance, pretty much everyone avoids ~750-850km in their LEO constellation planning because of the debris cloud from the one collision.
Collision avoidance is absolutely at the forefront of any satellite constellation. Starlink will have satellites crossing planes every second or multiples per second. Starlink is actively trying to push the lower limits of COLA thresholds so they don't have to perform an ungodly amount of maneuvers per day. There's room to evolve here for sure, and if anyone is going to make proper advances its SpaceX (automated COLAs, long term forecasting, etc), but assessing orbital debris from mega constellation collisions as anything short of "this is a huge deal" indicates a serious lack of subject matter understanding.
Space debris and the quantity of satellites being proposed by Starlink (and others, primarily Kuiper) is absolutely a huge deal and cannot in any way be understated.
Yes, my math is not exactly representative of the orbital planes, I was trying to demonstrate how huge the amount of space is, even at a single orbital altitude.
I fully agree that any collision would be ugly in a mega constellation, and you very much are correct that at specific areas the satellites will get much much closer together.
I am not by any means discounting the need for collision avoidance. From the way many people talk about it, they think of the proximity soon after deployment, not the proximity of the satellites once in the proper orbit and spacing.
-Harry
Similar threads
