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.

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".

All things being equal such as departure city and ease of access to the port, if they all sailed from the same port on the same day I'd rank them: 1. Freedom 2. Indy 3. Liberty If Liberty ever gets amped that could change. Truth be told they are all great ships and I'd sail them all but Liberty is in need of her postponed amplification.

Still waiting on 3 Odyssey and 1 Wonder block. September 2021 for the first Odyssey block.

Sorry for everything that has happened up to this point and I hope your wife begins to feel better soon. As far as Royal's position it does appear they should work on their wording which appears to suggest you should board with whatever possible infection may be present as long as it isn't "COVID-19". There has to be a better way to handle this scenario independent of the financial impact of no refund/no FCC which clearly they should not be expected to provide. Perhaps they are hesitant to state you shouldn't board as that implies they are instructing you not to cruise which could have implications in a legal or financial sense. For example if they "deny" you boarding (by telling you not to board) then a credit card company could look at that as if Royal failed as a merchant to provide the service you purchased. Disney charges outrageous prices so they can bury losses and still be profitable. As a company that is their prerogative to take this approach. That doesn't mean every other company on the planet should follow the Disney way. As a consumer I don't want to overpay for my purchases so that others can not follow policy. I feel terrible for everything your family is going through but I don't think Royal should deviate from their policy and grant you a refund or FCC. I state this as I myself will probably walk away from a cruise in a week knowing all I'll get back is port fees and taxes. My personal situation has changed since I booked this cruise and now with a week to go I accept that's on me. No refund, no FCC, no attempt will be made to lie or fake a false positive or any other means to weasel a refund. At this point unless there is a pop up hurricane induced refund option I will lose my money and I accept that is on me.

Royal has been testing higher cabana rates at Labadee given the seemingly endless number of guests willing to pay outrageous cabana pricing at CocoCay. When they jacked the rates there were fewer suite guests buying them at the new price point so they opened BB cabanas up to non-suite guests. There was a thread about this at the time. They still enforce suite only access for non-cabanas guests. In July I saw some interlopers booted from BB.

Long been that way.

Princess may have an opening because Royal built a new terminal and is moving. Without the new terminal it may have been difficult for Princess to secure weekend berthing.

Often GGG rates require full payment since they are within final payment due date. Once a booking is paid in full it can't be transferred. For the purpose of GGG your favorite TA not getting the booking isn't the end of the world. Commission typically is very little for GGG rates. Unless the cruise ends up cancelled by Royal there typically isn't a lot of servicing that a TA can perform on a cruise booked after final payment due date. Talk to you TA about it. That's what I did. She didn't lose sleep over a few GGG direct bookings I made.