twangster

O3b and it's beam forming technology that followed a ship was emerging technology in 2014. Starlink's used of phase array antennas and the shear number of satellites in different shells, inclinations and altitudes is also emerging technology. The company's stated purpose is to serve regions that are underserved. If you are in rural anywhere it's a game changer even if it isn't all that for metropolitan and larger populations centers where fiber is becoming more common. When your choice in the middle of nowhere is really weak cellular, nothing or Starlink the solution is fantastic even if it has some challenges at times. As long as Elon doesn't pull a Telsa Home Solar abrupt change of heart it has a lot of potential.

Right now Starlink can only support one hop to a gateway on land. At least in this region. They have started doing satellite to satellite relay but only closer towards the poles. That's how they are now selling Starlink in Alaska and Northern Canada. Once the v2 next gen Starlink satellites start going up it will be a game changer. Those will allow more hops between satellites to reach a gateway on land and that will extend the reach to more of the oceans farther from land. At least that's the Elon promise. The gen v2 satellites are also essential to the Elon vision of low latency Starlink. Starlink is "building the airplane as it flies". It's not nearly complete yet. My gut says it will one day provide excellent service on ships. We just need to be patient until they get there. I am hopeful next summer will see much improved Alaska ship internet. Time will tell.

Oasis just passed through heavy rain. My first experience with Starlink and rain like this. This was pretty heavy rain but very localized. The type of rain that would have knocked out O3b and Speedcast completely. During the rain: After the rain and once the skies were blue again: If folks were inside and doing simple texting they'd probably never know it rained. My results over this cruise:

BTW - The move to Starlink isn't to deliver better internet. It's all about switching to a cheaper supplier.

Before the shutdown Princess converted their last old ship to SES/O3b. They also don't use per user speed limits. It works really well. At times over 220Mbps. Royal was an important launch client for O3b with Quantum. However once they saw they could charge the same for Voom S&S and pull the wool over our eyes they stopped converting old ships to O3b. Why would they pay more for something they could market and sell no different than speedcast? In other words they learned they could charge the same for the old, slow and cheaper technology. At Royal it isn't about delivering on the marketing claim of "Fastest Internet at Sea". It's only about money.

The speed limits used in 2013 when Royal ladt did a fleet wide upgrade were good for the time. Home internet was typically 20 to 30 Mbps back them. Fast forward a decade and we've come a long ways over 10 years. Home internet is typically 200Mbps and many have 1Gbps at home. Yet Royal is still stuck in 2013 ways with the slowest internet at sea while other mass marketing lines have zoomed past Royal. Granted Starlink isn't fully operational. Only time will tell if Royal will attempt to retake the title of fastest internet at sea once Starlink is more complete.

Dec 20 - 8 pm After leaving Labadee it wasn't the best Voom on Oasis. On our way back to Miami on Oasis. Looks like we are retracing our route through the Sargosa Sea of bad internet. Dec. 21 6:30am This morning things are looking better on board. Where we had terrible iinternet on our way south it's now pretty usable albeit still with a 9x4 per user speed limit. This morning I've been able to stream from several sources, ESPN+ (which wouldn't stream last night), Netflix (which buffered last night) and Plex local TV stations from home (which failed last night). On board it's WiFi 5 using 20Mhz channels. On my balcony: Position It feels like we had an issue like a bad modem or antenna and they've fixed it.

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.

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.

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.

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.

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

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.

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

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.

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:

I never said a status match can't be achieved ahead of time. Ah hell, I give up. Another site to avoid for a while...

He's is welcome to mow my lawn anytime.

He can't. A never cruised guest has no entry in the CAS database until after they sail. He is a CAS nobody before he steps on board for the first time.

Given he has never sailed Royal he shouldn't have an address in the system. 🤣

February 2022 departure time lapse. Where we turned is near the location of the new cruise terminal that will open soon. Any sea can have rough weather and calm weather. Galveston in certain times of the year is known for fog more than terrible seas. Yet the seasonal fog is not a given, it all depends. The morning this video was taken there was fog yet the ship made it back into port safely and sail away was... pretty awesome.

I flew to every cruise for my first 750 points and I flew home with many crystal blocks, some times international, some times domestic. It was never a hassle. Sometimes I had two blocks with me. I tended to do B2B or S2S since I was flying and when near a block threshold it's common to get a block from both ships since the points don't post until a week after a cruise. That meant flying home with two blocks. Still not a hassle.

I had 8160 in November. Never heard any noise. The stairs and elevator lobby go through a fire door so it's not exactly wide open. I specifically chose this area. Out the door and into Central Park in a handful of steps. I look for cabins in this area for quick access to the elevators and Central Park. I'd book it again.

Captain Johnny: "I'm going to tweet that Royal just bought Carnival. Watch this... I'm going to commandeer terminal 3".

The enhanced embarking process is why the Crown and Anchor priority queues have become meaningless. Some people gripe when they hear there are no CAS based queues like before but what you describe for embarkation is what Royal started working towards before the pandemic. "Car to Bar in 15 minutes".