Starlink Equipped Ships

[A&L_Ont]

2 hours ago, Tree_skier said:

This is a crowd sourced document.

 

https://docs.google.com/spreadsheets/d/1kZ1gCFtt1eiX1OWw9q-8tnEU5uQCWIjBwQt-w3t040s/edit#gid=1881900306

 

It appears that Harmony still has O3B.  I'm sure it is changing fast though.  Hopefully you get lucky. 

In looking at the Voom type, is it safe to figure that O is for O3B and the S is for Starlink?

[Biker19]

Just now, A&L_Ont said:

In looking at the Voom type, is it safe to figure that O is for O3B and the S is for Starlink?

Yes, and L for legacy. 

[exm]

21 hours ago, Ret MP said:

I hope they keep tiers.  But, like I said, I believe in here some folks said that eventually with Star Link, the tiers will go away.  I hope not.  

 

I'm booked on the 1/13/23 Anthem sailing where Starlink supposedly is being installed. I checked online, and the ONLY internet option is "surf and stream" so it seems that's the Starlink tier. I've also noticed that the pricing model has changed for multiple lines, but that might be a fleet-wide thing.

[A&L_Ont]

49 minutes ago, Biker19 said:

Yes, and L for legacy. 

Dare I ask, “Legacy”… is that a cable dragged behind the ship to shore?

[Biker19]

27 minutes ago, A&L_Ont said:

Dare I ask, “Legacy”… is that a cable dragged behind the ship to shore?

Geosynchronous sat. 

[John&LaLa]

1 hour ago, A&L_Ont said:

In looking at the Voom type, is it safe to figure that O is for O3B and the S is for Starlink?

 

SpaceX is launching two O3B satellites this afternoon. Hoping Serenade gets O3B added as backup for our time in  the Pacific, Asia, and Indian Ocean 

[Ret MP]

16 minutes ago, John&LaLa said:

 

SpaceX is launching two O3B satellites this afternoon. Hoping Serenade gets O3B added as backup for our time in  the Pacific, Asia, and Indian Ocean 

I never get enough of Space activity:

 

https://www.spacex.com/launches/mission/?missionId=SES-O3b-mPOWER

[TheHomelessCruiser]

2 hours ago, John&LaLa said:

 

SpaceX is launching two O3B satellites this afternoon. Hoping Serenade gets O3B added as backup for our time in  the Pacific, Asia, and Indian Ocean 

 

The folks at SES/O3b must be cursing the fact they have to pay SpaceX to launch their birds when Starlink is stealing their customers and driving down satellite internet rates.

[Tree_skier]

4 hours ago, A&L_Ont said:

In looking at the Voom type, is it safe to figure that O is for O3B and the S is for Starlink?

That is my assumption.

[twangster]

On Oasis. 

 

Long post that's a bit technical.  As a network geek I'm sharing some details for other geeks to review and consider.

 

Some Speedtests.

 

 

 

"curl" is a linux command that can be used to obtain details about network activity.  One check "curl" can perform is to lookup your public IP address.

 

Running several "curl" commands consecutively for about 15 seconds yielded these public IP addresses:

 

129.222.83.83
98.97.173.134
129.222.82.93
98.97.172.99
129.222.82.93
98.97.168.194
98.97.175.9
129.222.82.225
129.222.83.60
98.97.172.99
98.97.175.9
98.97.174.221
129.222.80.247
129.222.83.60
129.222.83.45
129.222.83.45
129.222.82.93
98.97.172.99
129.222.83.83
129.222.83.32
129.222.80.247
98.97.168.194
98.97.170.217
98.97.170.217
129.222.80.107
98.97.173.134
129.222.83.45
129.222.83.32
129.222.80.107
129.222.80.247
129.222.83.60
129.222.82.93
98.97.175.9
129.222.80.247
98.97.172.99
129.222.80.247
98.97.175.9
 

Normally at home or on a pre-migration ship that used the old satellite providers before Starlink the public IP address would not change like this.

 

Given the IP address changes every few seconds I suspect they are load balancing connections across all the antennas.  We know Royal installs multiple antennas, somewhere between 6 and 8 typically.  I suspect they do this since the Starlink maritime service is limited to ~350Mbps per modem/antenna.  By operating several Starlink maritime modems and antennas in tandem they can distribute the load across them and achieve an aggregate speed n x 350Mbps.  

 

Each session a user starts is treated separately.  One may go through antenna #1 and the next through antenna #6.  In repeating the public IP address check VIA the curl command each curl command is a unique session and each was sent VIA a different modem/antenna.  

 

Not all that glitters is gold.

 

Shortly after leaving Miami with a sky full of stars the internet was terrible.

 

ping google.com

PING google.com (172.217.15.206): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

64 bytes from 172.217.15.206: icmp_seq=0 ttl=107 time=3706.334 ms

64 bytes from 172.217.15.206: icmp_seq=1 ttl=107 time=3439.740 ms

Request timeout for icmp_seq 5

Request timeout for icmp_seq 6

64 bytes from 172.217.15.206: icmp_seq=4 ttl=108 time=3271.785 ms

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

Request timeout for icmp_seq 10

64 bytes from 172.217.15.206: icmp_seq=6 ttl=108 time=5275.419 ms

64 bytes from 172.217.15.206: icmp_seq=7 ttl=107 time=4666.947 ms

64 bytes from 172.217.15.206: icmp_seq=9 ttl=108 time=3839.767 ms

64 bytes from 172.217.15.206: icmp_seq=10 ttl=107 time=2881.380 ms

Request timeout for icmp_seq 15

^C

--- google.com ping statistics ---

17 packets transmitted, 7 packets received, 58.8% packet loss

round-trip min/avg/max/stddev = 2881.380/3868.767/5275.419/770.748 ms

 

Not long after that...

 

ping 4.2.2.3

PING 4.2.2.3 (4.2.2.3): 56 data bytes

Request timeout for icmp_seq 0

64 bytes from 4.2.2.3: icmp_seq=1 ttl=51 time=515.752 ms

Request timeout for icmp_seq 2

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

Request timeout for icmp_seq 5

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=98.915 ms

64 bytes from 4.2.2.3: icmp_seq=7 ttl=51 time=146.661 ms

64 bytes from 4.2.2.3: icmp_seq=8 ttl=51 time=336.066 ms

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=241.467 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=260.805 ms

64 bytes from 4.2.2.3: icmp_seq=11 ttl=51 time=350.234 ms

64 bytes from 4.2.2.3: icmp_seq=12 ttl=51 time=325.137 ms

64 bytes from 4.2.2.3: icmp_seq=13 ttl=51 time=322.316 ms

64 bytes from 4.2.2.3: icmp_seq=14 ttl=51 time=164.392 ms

64 bytes from 4.2.2.3: icmp_seq=15 ttl=51 time=362.071 ms

64 bytes from 4.2.2.3: icmp_seq=16 ttl=51 time=205.959 ms

64 bytes from 4.2.2.3: icmp_seq=17 ttl=51 time=402.587 ms

64 bytes from 4.2.2.3: icmp_seq=18 ttl=51 time=218.134 ms

64 bytes from 4.2.2.3: icmp_seq=19 ttl=51 time=238.396 ms

64 bytes from 4.2.2.3: icmp_seq=20 ttl=51 time=161.384 ms

64 bytes from 4.2.2.3: icmp_seq=21 ttl=51 time=276.768 ms

64 bytes from 4.2.2.3: icmp_seq=22 ttl=51 time=197.477 ms

64 bytes from 4.2.2.3: icmp_seq=23 ttl=51 time=315.996 ms

 

I still appeared to be using a Starlink public IP address so we didn't revert to O3b, these are Starlink latency numbers.  

 

Right this moment as I type this post:

 

ping 4.2.2.3                                           

PING 4.2.2.3 (4.2.2.3): 56 data bytes

Request timeout for icmp_seq 0

64 bytes from 4.2.2.3: icmp_seq=1 ttl=51 time=65.922 ms

64 bytes from 4.2.2.3: icmp_seq=2 ttl=51 time=41.868 ms

64 bytes from 4.2.2.3: icmp_seq=3 ttl=51 time=46.399 ms

Request timeout for icmp_seq 4

64 bytes from 4.2.2.3: icmp_seq=5 ttl=51 time=45.120 ms

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=39.903 ms

64 bytes from 4.2.2.3: icmp_seq=7 ttl=51 time=37.252 ms

64 bytes from 4.2.2.3: icmp_seq=8 ttl=51 time=48.913 ms

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=41.369 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=42.334 ms

64 bytes from 4.2.2.3: icmp_seq=11 ttl=51 time=39.647 ms

64 bytes from 4.2.2.3: icmp_seq=12 ttl=51 time=70.350 ms

^C

--- 4.2.2.3 ping statistics ---

13 packets transmitted, 11 packets received, 15.4% packet loss

round-trip min/avg/max/stddev = 37.252/47.189/70.350/10.400 ms

 

 

 

curl results over 5 seconds:

 

129.222.83.60
98.97.173.212
98.97.172.99
129.222.83.83
98.97.168.194
98.97.172.99
98.97.170.217
98.97.173.212
129.222.82.93
98.97.175.9
98.97.168.194

 

Our position:

 

[Biker19]

10 minutes ago, twangster said:

We know Royal installs multiple antennas, somewhere between 6 and 8 typically. 

I looked pretty hard on Enchantment but could only see 2- I suspect the other Vision class are similar.

[twangster]

14 minutes ago, Biker19 said:

I looked pretty hard on Enchantment but could only see 2- I suspect the other Vision class are similar.

 

On Jewel there are 4 above the VCL and 4 on top of the Sky Bar.  Those are hard to see but I saw them installing them so I knew to look there.

 

 

It helps to have a 360 camera on a stick.  Sky Bar antennas after installation was complete.

 

 

 

VCL:

 

 

On Adventure there are some on the VCL roof and some on the forward most roof above the forward public deck where mini-golf is on her sister ships.  

 

 

They seem to split the locations which I suspect is done for diversity.  If ship heading and angle makes some antennas partially shadowed then hopefully the others have a clear sky.  

 

Given that Jewel has 8 antennas I would have thought they'd do something similar on Vision class.  Maybe the best way to find them will be from another ship across the pier, assuming you are on a taller ship. 

[twangster]

Bad patch of the ocean right now.

 

ping 4.2.2.3

PING 4.2.2.3 (4.2.2.3): 56 data bytes

64 bytes from 4.2.2.3: icmp_seq=0 ttl=51 time=297.987 ms

64 bytes from 4.2.2.3: icmp_seq=1 ttl=51 time=313.433 ms

Request timeout for icmp_seq 2

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

Request timeout for icmp_seq 5

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=396.928 ms

Request timeout for icmp_seq 7

64 bytes from 4.2.2.3: icmp_seq=8 ttl=51 time=440.882 ms

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=328.279 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=354.751 ms

Request timeout for icmp_seq 11

64 bytes from 4.2.2.3: icmp_seq=12 ttl=51 time=301.006 ms

64 bytes from 4.2.2.3: icmp_seq=13 ttl=51 time=322.723 ms

^C

--- 4.2.2.3 ping statistics ---

14 packets transmitted, 8 packets received, 42.9% packet loss

round-trip min/avg/max/stddev = 297.987/344.499/440.882/47.304 ms

                         

98.97.173.134

98.97.175.9

129.222.83.60

129.222.83.83

98.97.172.99

 

24° 47.08' N

75° 20.32' W

 

 

[twangster]

I suspect we will all endure some issues until SpaceX gets Starship flying and the next gen Starlink v2 satellites go up.  Those should help to interconnect everything together and eliminate some of these poor performance issues.  

 

By mid-2023 it should start to work better... I hope.  

[twangster]

Not going to lie... this is the worst internet day I've ever experienced on a Royal ship.  Like Carnival 2012 internet bad at the moment.   

 

Can't post pictures.  VPN won't stay connected if it does connect.  

 

Variable light clouds in the sky.  Sunny at the moment.  Some areas of blue sky, some passing light clouds but not raining. Flat seas.  We are taking the Northern/Eastern route above and outside of the Bahamas to reach Labadee.  Must be no Starlink gateways out this way so we are relaying way too far back to the mainland.  I think if we had taken the Straits of Florida to get there we'd have better internet.  

 

24° 06.95 N

74° 48.72 W

 

There will be no working remotely this cruise.  I did a lot better back in October on Jewel before they moved her to Starlink.

 

0.22 Mbps down

0.79 Mbps up. 

622ms according to Speedtest.

129.222.82.225 - SpaceX Starlink

 

ping 4.2.2.3

PING 4.2.2.3 (4.2.2.3): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

64 bytes from 4.2.2.3: icmp_seq=2 ttl=51 time=432.418 ms

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

Request timeout for icmp_seq 5

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=441.069 ms

64 bytes from 4.2.2.3: icmp_seq=7 ttl=51 time=460.260 ms

Request timeout for icmp_seq 8

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=438.348 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=429.577 ms

64 bytes from 4.2.2.3: icmp_seq=11 ttl=51 time=419.385 ms

Request timeout for icmp_seq 12

Request timeout for icmp_seq 13

Request timeout for icmp_seq 14

Request timeout for icmp_seq 15

64 bytes from 4.2.2.3: icmp_seq=16 ttl=51 time=437.568 ms

64 bytes from 4.2.2.3: icmp_seq=17 ttl=51 time=414.761 ms

^C

--- 4.2.2.3 ping statistics ---

19 packets transmitted, 8 packets received, 57.9% packet loss

round-trip min/avg/max/stddev = 414.761/434.173/460.260/13.118 ms

[Biker19]

36 minutes ago, twangster said:

this is the worst internet day I've ever experienced on a Royal ship.

It's gotta get better, right? I mean it can't get any worse?

[Ret MP]

Royal's latest IT innovations:

 

 

[ticketsunlimited]

Okay Got it.

[Ret MP]

8 hours ago, twangster said:

On Oasis. 

 

Long post that's a bit technical.  As a network geek I'm sharing some details for other geeks to review and consider.

 

Some Speedtests.

 

 

 

"curl" is a linux command that can be used to obtain details about network activity.  One check "curl" can perform is to lookup your public IP address.

 

Running several "curl" commands consecutively for about 15 seconds yielded these public IP addresses:

 

129.222.83.83
98.97.173.134
129.222.82.93
98.97.172.99
129.222.82.93
98.97.168.194
98.97.175.9
129.222.82.225
129.222.83.60
98.97.172.99
98.97.175.9
98.97.174.221
129.222.80.247
129.222.83.60
129.222.83.45
129.222.83.45
129.222.82.93
98.97.172.99
129.222.83.83
129.222.83.32
129.222.80.247
98.97.168.194
98.97.170.217
98.97.170.217
129.222.80.107
98.97.173.134
129.222.83.45
129.222.83.32
129.222.80.107
129.222.80.247
129.222.83.60
129.222.82.93
98.97.175.9
129.222.80.247
98.97.172.99
129.222.80.247
98.97.175.9
 

Normally at home or on a pre-migration ship that used the old satellite providers before Starlink the public IP address would not change like this.

 

Given the IP address changes every few seconds I suspect they are load balancing connections across all the antennas.  We know Royal installs multiple antennas, somewhere between 6 and 8 typically.  I suspect they do this since the Starlink maritime service is limited to ~350Mbps per modem/antenna.  By operating several Starlink maritime modems and antennas in tandem they can distribute the load across them and achieve an aggregate speed n x 350Mbps.  

 

Each session a user starts is treated separately.  One may go through antenna #1 and the next through antenna #6.  In repeating the public IP address check VIA the curl command each curl command is a unique session and each was sent VIA a different modem/antenna.  

 

Not all that glitters is gold.

 

Shortly after leaving Miami with a sky full of stars the internet was terrible.

 

ping google.com

PING google.com (172.217.15.206): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

64 bytes from 172.217.15.206: icmp_seq=0 ttl=107 time=3706.334 ms

64 bytes from 172.217.15.206: icmp_seq=1 ttl=107 time=3439.740 ms

Request timeout for icmp_seq 5

Request timeout for icmp_seq 6

64 bytes from 172.217.15.206: icmp_seq=4 ttl=108 time=3271.785 ms

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

Request timeout for icmp_seq 10

64 bytes from 172.217.15.206: icmp_seq=6 ttl=108 time=5275.419 ms

64 bytes from 172.217.15.206: icmp_seq=7 ttl=107 time=4666.947 ms

64 bytes from 172.217.15.206: icmp_seq=9 ttl=108 time=3839.767 ms

64 bytes from 172.217.15.206: icmp_seq=10 ttl=107 time=2881.380 ms

Request timeout for icmp_seq 15

^C

--- google.com ping statistics ---

17 packets transmitted, 7 packets received, 58.8% packet loss

round-trip min/avg/max/stddev = 2881.380/3868.767/5275.419/770.748 ms

 

Not long after that...

 

ping 4.2.2.3

PING 4.2.2.3 (4.2.2.3): 56 data bytes

Request timeout for icmp_seq 0

64 bytes from 4.2.2.3: icmp_seq=1 ttl=51 time=515.752 ms

Request timeout for icmp_seq 2

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

Request timeout for icmp_seq 5

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=98.915 ms

64 bytes from 4.2.2.3: icmp_seq=7 ttl=51 time=146.661 ms

64 bytes from 4.2.2.3: icmp_seq=8 ttl=51 time=336.066 ms

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=241.467 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=260.805 ms

64 bytes from 4.2.2.3: icmp_seq=11 ttl=51 time=350.234 ms

64 bytes from 4.2.2.3: icmp_seq=12 ttl=51 time=325.137 ms

64 bytes from 4.2.2.3: icmp_seq=13 ttl=51 time=322.316 ms

64 bytes from 4.2.2.3: icmp_seq=14 ttl=51 time=164.392 ms

64 bytes from 4.2.2.3: icmp_seq=15 ttl=51 time=362.071 ms

64 bytes from 4.2.2.3: icmp_seq=16 ttl=51 time=205.959 ms

64 bytes from 4.2.2.3: icmp_seq=17 ttl=51 time=402.587 ms

64 bytes from 4.2.2.3: icmp_seq=18 ttl=51 time=218.134 ms

64 bytes from 4.2.2.3: icmp_seq=19 ttl=51 time=238.396 ms

64 bytes from 4.2.2.3: icmp_seq=20 ttl=51 time=161.384 ms

64 bytes from 4.2.2.3: icmp_seq=21 ttl=51 time=276.768 ms

64 bytes from 4.2.2.3: icmp_seq=22 ttl=51 time=197.477 ms

64 bytes from 4.2.2.3: icmp_seq=23 ttl=51 time=315.996 ms

 

I still appeared to be using a Starlink public IP address so we didn't revert to O3b, these are Starlink latency numbers.  

 

Right this moment as I type this post:

 

ping 4.2.2.3                                           

PING 4.2.2.3 (4.2.2.3): 56 data bytes

Request timeout for icmp_seq 0

64 bytes from 4.2.2.3: icmp_seq=1 ttl=51 time=65.922 ms

64 bytes from 4.2.2.3: icmp_seq=2 ttl=51 time=41.868 ms

64 bytes from 4.2.2.3: icmp_seq=3 ttl=51 time=46.399 ms

Request timeout for icmp_seq 4

64 bytes from 4.2.2.3: icmp_seq=5 ttl=51 time=45.120 ms

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=39.903 ms

64 bytes from 4.2.2.3: icmp_seq=7 ttl=51 time=37.252 ms

64 bytes from 4.2.2.3: icmp_seq=8 ttl=51 time=48.913 ms

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=41.369 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=42.334 ms

64 bytes from 4.2.2.3: icmp_seq=11 ttl=51 time=39.647 ms

64 bytes from 4.2.2.3: icmp_seq=12 ttl=51 time=70.350 ms

^C

--- 4.2.2.3 ping statistics ---

13 packets transmitted, 11 packets received, 15.4% packet loss

round-trip min/avg/max/stddev = 37.252/47.189/70.350/10.400 ms

 

 

 

curl results over 5 seconds:

 

129.222.83.60
98.97.173.212
98.97.172.99
129.222.83.83
98.97.168.194
98.97.172.99
98.97.170.217
98.97.173.212
129.222.82.93
98.97.175.9
98.97.168.194

 

Our position:

 

Ya, what he said!

[twangster]

For those that seek a better understanding how Starlink works go to starlink.sx in a browser on a laptop or desktop computer (doesn't support mobile devices).

 

This site is an unaffiliated simulation of the Starlink satellites flying in the sky.  Zoom in, right click on a location to set a simulated earth station and you'll see the satellites that would be serving that location along with the gateways on land that would be used.  

 

Oasis is arriving into Labadee right now.  From here we are leveraging gateways in the Dominican Republic, Puerto Rico and Florida.  

 

 

Each ship to satellite to gateway path is a different length and constantly changing as the satellites fly overhead.

 

 

This explains the variable latency or delay that a ping test displays.  Each line is taking a different path through different satellites and gateways.

 

ping 4.2.2.3                           

PING 4.2.2.3 (4.2.2.3): 56 data bytes

64 bytes from 4.2.2.3: icmp_seq=0 ttl=51 time=123.460 ms. <- one satellite/gateway path

64 bytes from 4.2.2.3: icmp_seq=1 ttl=51 time=131.023 ms. <- 2nd satellite/gateway path

64 bytes from 4.2.2.3: icmp_seq=2 ttl=51 time=63.672 ms <- 3rd satellite/gateway path

64 bytes from 4.2.2.3: icmp_seq=3 ttl=51 time=114.756 ms <- 4th satellite/gateway path

64 bytes from 4.2.2.3: icmp_seq=4 ttl=51 time=57.871 ms <- 5th satellite/gateway path

64 bytes from 4.2.2.3: icmp_seq=5 ttl=51 time=302.609 ms <- 6th satellite/gateway path

64 bytes from 4.2.2.3: icmp_seq=6 ttl=51 time=312.364 ms

64 bytes from 4.2.2.3: icmp_seq=7 ttl=51 time=106.913 ms

64 bytes from 4.2.2.3: icmp_seq=8 ttl=51 time=314.867 ms

64 bytes from 4.2.2.3: icmp_seq=9 ttl=51 time=213.740 ms

64 bytes from 4.2.2.3: icmp_seq=10 ttl=51 time=85.836 ms

 

Each ping is through a different antenna mounted on the ship.  There are several antennas on the ship.  Each independent path has a different IP address.  IP addresses being used by Oasis right now below are associated to gateway cities, some in the DR, some in PR and some on the mainland.

 

129.222.83.60
129.222.83.45
98.97.175.9
98.97.168.194
98.97.172.99
129.222.80.107
98.97.174.221
98.97.173.212
129.222.82.93
129.222.82.225
 

This explains why my VPN session only lasts for a few minutes then drops - that path is no longer available because the satellite it was using has gone out of range.  I can reconnect my VPN and it works fine until that satellite flies out of range then it disconnects.  Rinse, lather, repeat.

 

For general internet browsing and streaming it's great.  For working remotely from a ship that requires VPN back to corporate Starlink may not work very well.  

 

SSL VPN may work better than IPSEC VPN, it depends.

 

YMMV.

Edited December 20, 2022 by twangster

[twangster]

Found 16 Starlink antennas on Oasis. 

 

There are 12 in a semi-circle along the edge of the CK/SL roof. 

 

 

There are 4 on the roof above the suite sun deck, 2 on the port side and 2 on the starboard side. 

 

 

 

 

 

[twangster]

For Oasis I have observed that there are 15 IP addresses that I have used at various times.  Running several tests these addresses repeat in a random fashion.

 

98.97.168.194
98.97.170.217
98.97.172.99
98.97.173.134
98.97.173.212
98.97.174.221
98.97.175.9
129.222.80.107
129.222.80.247
129.222.82.93
129.222.82.225
129.222.83.32
129.222.83.45
129.222.83.60
129.222.83.83
 

Since there appears to be 16 Starlink antennas on the ship it seems likely that each of these IP addresses represents one antenna and that antennas connection to the internet.

 

One antenna IP address is missing if there are 16 antennas.  It's possible one antenna is a cold spare or it's dedicated to another function such as bridge internet, crew internet or internet for the ship and all the IOT devices on the ship.  By dedicating one antenna to this role they have a static IP address so it's easy to create HQ VPN tunnels or HQ firewall rules for this function.

 

Unknown if these will change over time.

 

All of these IP addresses resolve to customer.atlagax1.pop.starlinkisp.net which suggests they are in Atlanta, GA.  All of my speedtest.net tests have used Atlanta based speed test servers.  All of these addresses trace back to Atlanta. 

 

So it seems Oasis VIA Starlink appears to be connecting to the internet in Atlanta.  

[twangster]

So why is all this techno geek stuff important?

 

If I am right it means there is a theoretical aggregate bandwidth of 15 x 350Mbps = 5.2 Gbps on Oasis. 

 

It make take more deployment of additional Starlink satellites to realize that potential throughput but if it is true, it means there are great things ahead for the Voom user experience.  

[Ret MP]

11 minutes ago, twangster said:

So it seems Oasis VIA Starlink appears to be connecting to the internet in Atlanta.  

That's because that's where the Points and Plugs are!

[Ozark_Kid]

On 12/19/2022 at 12:16 PM, Ret MP said:

Royal's latest IT innovations:

 

 

I will have to admit I was getting confused but after watching the video all is good.  Thanks!