FWIW, it's perfectly possible to simulate arbitrary levels of bandwidth/latency with a variety of tools even while having a fiber connection. For example, Macs have long had the "Network Link Conditioner" tool as a free utility included with the Additional Tools for Xcode package, which then allows simulating configurable bandwidth, latency, and packet loss. There are similar tools for Linux as well, tc is powerful. Most firewalls with quality traffic shapers also allow at least the first two at the network level, I used that on OPNsense to simulate a VSAT connection with 750ms latency and 4/.5 to a specific VLAN so that we could just connect systems and then see how applications worked. It's been awhile but it was eye opening. A nice thing about that approach is that then you can just connect devices to a given VLAN, which makes testing back and forth super easy. Wired is trivial of course, have a switch where each port is a different test VLAN, but even for wireless if you have WAPs that support PPSK/MPSK, then hopping between test VLANs just means reconnecting with a different password. Simulating packet loss with a network device seems the be more niche and complicated and I don't know if any firewalls put a GUI on it. tc queue disciplines can be used though so any Linux device with two network ports can sit inline and modify the traffic to simulate loss/latency, an RPi would be fine for that.
I agree it'd be nice if more app developers would test under less than ideal conditions, particularly since it's so trivial to do so. I think most simply don't think about it though, same as many GUIs (web or local) not testing for stuff like various types of color blindness.
That's the way real networks behave, and what real users have to manage with.
Yes it is perfectly possible, but it’s very difficult. Having just gone through this process I can attest that this is not something the average “app developer” is going to be capable of doing, at least on Linux and Windows.
The raw tools are there, but they are complicated, poorly documented, and require network engineering knowledge on top of software development knowledge.
Probably there is some nice package to wrap up the whole “generate a virtual network and add latency + packet loss between these two end points”, I just never found it.
Linux has a built-in command: trickle
https://linux.die.net/man/1/trickle
https://stackoverflow.com/questions/10328568/simulate-limite...
As for how hard it actually is: iOS has already been explained, the Android emulator has network latency and speed simulation right in the GUI, as do most web browsers. And there's alway the option to switch your phone to 2G only in the settings and/or go into the basement or elevator.
This is the real problem - there are deadlines and most projects don't even consider working in questionable network conditions. Developers aren't going to put in the extra effort when it doesn't contribute to the job they are asked to do.
I always at least _ask_ in the requirements gathering stage for a new mobile app: "how much effort do we want to dedicate to app performance/reliability under marginal network conditions?"
As it turns out, pretty much all mobile app owners are as apathetic about that as most mobile app developers. (On the other hand, once you've got a reputation for being able to handle those sorts of flaky network edge cases, you get more and more work for the sort of apps that benefit from them. The downside of that is it's never the flashy resume-building-apps that come to you for this.)
shrug
Disagree, it's no harder than any other linux subsystem, you can use `tc` or you can attack it a different way by using virtualization then messing with it at the vde layer. I've added storage and network random latency for testing code before, took a day or so to get working perfectly, but now it's in a shell script.
Hm, alternatively.... you're right, it's very difficult. You should hire a software engineer, such as myself, to do it for you. ;-) ;-)
Both Firefox and Chrome dev tools also have built in throttling of network connections. https://blog.nightly.mozilla.org/2016/11/07/simulate-slow-co...
The tools exist and they're easy to use. Most people just don't bother.
Well, I sure wish Apple would make use of that functionality themselves once in a while.
It's frustratingly impossible to enqueue an iMessage message while out of signal and have it be automatically delivered once back in cell coverage. Bizarrely WhatsApp, a third-party application (with all the background execution restrictions that go with that), manages to do just that!
I had to rearchitect an entire file synchronization and uplink system for resilience while sitting in a hotel room in the middle of a blizzard during the shortest days of the year so I could deploy software for clients up there.
I found your uplink. IDK the date of the photo.
https://uploads.alaska.org/blog/Carl-Johnson-Blog/Kotzebue/_...
There's very little bandwidth you need when you're in the backcountry, especially given some reasonable pre-download of maps and other information.
Direct to phone satcom is neat and I can see plenty of applications for it but I know that I wouldn't stake my life on it simply due to it being a consumer-grade phone.
I do carry a spare battery etc. I suppose I could keep my phone in a rugged case in my pack and use something else for pictures and maps but that's sort of getting away from the idea of one device you always have right with you.
I think your concern is warranted as vehicle accidents and falls may call into question the durability of the device in question however based on the mix of accidents and especially the prevalence of medical misadventures its probably a worthwhile feature even if you don't opt for something desired for extra durability.
Another logical concern is battery life. A huge chunk of non-fatal misadventures are day hikers and the dominant cause is actually dummies wandering off trail as opposed to injury.
I laughed at that picture of the mountaineer in full Alpine climbing attire, on a tablet.
What's he doing on it, checking his email? The view behind him isn't good enough?
I do carry an InReach when I hike in remote areas but if my phone could make satellite emergency communications, I'd stop paying $144 a year for the InReach.
If InReach dropped the price to $50/year, then I'd consider still subscribing to it.
I got a 4g nokia dumb phone just for this occasion - few days of battery life, sturdy build, good for small trips/hikes where you usually have signal or as a backup phone
for me, even just driving to the next town over, or going for a bike ride that takes me less than two hours from my house, there's places where the cell connection cuts out. i'm not packing an inreach for an hour drive, but it's nice to know that if i need it i can count on my cell phone.
I like how I can tell an iPhone that a wifi AP is a “low bandwidth” one so it holds off on many tasks. But you can screw yourself over if you tether a computer, even a Mac.
You should try WhatsApp - there really are not many messenger choices when you have unreliable 2G(!) connectivity. For all the faults of Meta, WhatsApp seems to be the only company that cares about people with bandwidth measured in kbps, sometimes fractions thereof.
That can’t be said of iMessage.
Edit: I sometimes get a chuckle when they say "Look at this cool picture I took", and then receive the picture some days later when the conversation thread has moved on. I guess they'd have stayed in thr coverage area for long enough for the entire image to upload.
Sometimes sms failover creates further problems because when travelling you’re more likely to have intermittent wifi than intermittent sms access.
I hoped that Signal's use of HTTP was as a fallback in case a direct connection could not be established to use a more "compact" protocol, but I possibly don't remember correctly what I've read...
WhatsApp was built with low-bandwidth/high-latency/high-packet-loss in mind well before Meta acquired them.
I suppose we can give them vague amounts of credit for not making those use cases worse since the acquisition.
It used to work just fine on 1kbps.
Now it is pretty much unusable over dialup or GPRS.
For example, messaging a contact with multiple devices connected means that your phone has to encrypt your message to each of their clients independently.
Cheap, fucking indestructible, and you could probably bludgeon someone to death with it in a pinch.
It also has a thermal imaging camera which is surprisingly handy for stuff like “finding where in the garden my cat is hiding at night” or “figuring out what’s overheating” or monitoring the state of my compost bin.
My InReach (I have an Explorer, not the mini) is an exceedingly rugged bit of kit with an effectively infinite battery life.
It is, by no means, a sleek or svelte device like my iPhone but if I fell down on a trail and broke all my fingers (or had severe frostbite or something) I'm fairly confident I could operate the device with some combination of my teeth, nose and toes.
I'm also fairly sure that it will keep functioning even if I had accidentally dropped it off a cliff, in a blizzard, into an ocean.
The mini is basically the same kind of rugged so you know exactly what I mean :)
The battery also lasts basically forever.
I turned mine on about 48h ago before a trip and it's been on ever since and I just checked and the battery is at 86% with 2-minute tracking intervals.
Anyway I am still very happy for the starlink service for the 99% of people who don't have an InReach, it will definitely save lives, I'm just not yet ready to ditch my InReach.
Before getting an InReach, confirm a 406MHz emergency beacon doesn't fit your bill [1][2]. (I have this one [3].)
You can't text a loved one. But with no subscription, a years-long battery and powerful radio that works around the world, you can call emergency services to your precise location.
[1] https://www.sarsat.noaa.gov/emergency-406-beacons/
[2] https://www.rei.com/learn/expert-advice/personal-locator-bea...
[3] https://www.rei.com/product/161982/acr-electronics-resqlink-...
Any emergency beacon is better than none, but two-way communication can be a literal lifesaver. I hope that the Starlink system is eventually linked into our 911 infrastructure and available to anyone with an LTE phone regardless of carrier.
Also to communicate on-the-fly decision-making to inform potential SAR - "I'm making good time, going to head up this extra peak before continuing the planned route."
I'm happy to have a cell phone backup to the inReach, but I don't see this Starlink offering as a replacement. That goes double if you're out in winter. Phone batteries aren't great in the cold.
You should have no problem with that anywhere in the world as long as you keep it in an inner pocket. Perhaps pack wired earphones just in case you need to make a long call while keeping the phone itself warm.
Notably the battery should not be charged below about 5C. If you do, it will be permanently damaged.
This depends on the specific battery chemistry. The BMS should prevent the charging scenarios which would damage the battery. For some it's 0C not 5C. Some can handle charging below 0C.
Even the cheapest chips from TI and ST seem to include it. And modern cell phones often advertise extra-fast 20W+ charging, so I doubt they're using the cheapest chips.
They've been the only ones that don't just turn off in really cold temperatures, even without babying them in warm pockets.
The general ruggedness is also pretty good to amazing, depending on how fragile your previous phones were. For example: it survived a ~10 meter (32ft) drop on rocks, whereas everyone was convinced it was done for.
To be honest I first thought it would be a gimmick, but being able to see heat / rough temperature degrees has proven itself quite useful.
But you don't really realize it until you have it available. It's kind of like having another sense available to you.
Random examples of where it was useful:
- finding shitty chargers/electronics which were really hot while doing nothing -> wasted power
- spotting a water leak before it was visible (think cold spot in the middle of the ceiling)
- checking car tire alignment (one side hotter than the other)
- finding buried hot water pipes
- finding where cold air is leaking in during winter
- spotting damp areas
and probably others that I'm forgetting right now
I had that in my hometown in eastern France at 800m altitude, a town a few km away has a record of -41. -15/-20c was almost a yearly occurance when I was a kid
Once I was stuck with a ridesharing car opened and off in -20C because my old samsung s8 throttled so bad I couldn't even reboot it. It was completely unresponive with the flashlight still on discharging it even faster.
I couldn't leave the car too, being responsible for damages during the rent.
After a bit of time I remembered that to force shut down newer androids you have to hold volume down and power. Why would they not keep it as a long press is beyond me.
If Starlink's solution is really completely unmodified LTE, I'd expect 911 calls to work regardless of being a T-Mobile subscriber, just like for existing terrestrial networks (where you can dial 911 even if your carrier does not have signal in a given location, or even entirely without a SIM card).
The satellites can correct for "global" latency themselves (unless there are higher-level parts of the LTE/E-UTRA radio protocol that can't tolerate such long latencies, e.g. ARQ timers).
For GSM as a half-duplex technology, there's also the matter of devices not being able to transmit and receive at the same time, but I believe the same principle applies: As long as the timing differences between different devices in the same spot beam isn't too large, that's something the satellites could globally correct for.
The same probably applies for doppler corrections.
And couldn’t the satellites mostly adjust for that, given that the relative doppler shift should be pretty constant between mobiles in the same spot beam?
https://eudl.eu/pdf/10.1007/978-3-319-66628-0_41
doppler shift is not a constant for a stationary observer from Earth.
With PLB, satellites can't accurately measure where the PLB is; the search and rescue crew will find you by local radio reception.
With a satellite messenger, the gadget knows its own GPS location to a pinpoint and can send that as part of the SOS signal. And you can text the SAR staff and say "I fell and I'm now stuck on a tall ledge halfway up the cliff".
I guess this is the first time it's occurred to me that hikers and backpackers and such carry them too, which is odd because I hike and backpack.
I picked up the InReach after finding myself 200 miles offshore in a sailboat without an engine or battery power (which meant no VHF or electronic navigation equipment or autopilot or even red/green lights for others to see us at night) nor any way to make power
I assume the 406 Mhz beacon has a range of a few miles?
Other than the compass (which was only visible in the day time) the EPIRB was the only piece of equipment we assumed to work on the aforementioned voyage. We of course didn't test it as we were able to make it back safely, but I should probably learn more about how it functions.
We were sailing like demons. One of my biggest regrets of the trip was that we didn't have any wind or speed instrumentation to let us know how fast we were going, but it felt extremely fast.
They’re very safe, last something like 10 years, and aren’t really expensive (compared to “I need to know what direction I’m going and have no way to do so, or can’t see it”).
There are also lots of established shipping lanes you could find that would be relatively densely traveled and give you periodic feedback for which direction to go. A bit more dangerous due to collisions without lights but as long as your retroreflector is hoisted, big ships should see you clearly on radar. plus you’ll generally be swapping sleep shifts and always have someone manning the helm on the sailboat, though seeing large vessels at night can be somewhat more difficult.
The only other complicating factor was that due to the August Florida heat, nobody really had the luxury of sleep for the first couple of days.
My experience in Marine SAR is that this is no longer true. Apps like Navionics, SeaPilot, etc - often without any backup at all - are by far the most common form of navigation.
There were lots of red flags before finding ourselves in squarely over our heads -- an overheating motor was explained away as having had an undersized thermostat installed. Plausible enough. The lack of a bimini in August in Florida was just forgotten, but led to pretty significant overheating to me. The autopilot not working we didn't realize until about 15 miles offshore. That the autopilot was draining all the other batteries we didn't realize until we lost navigation lights. Etc. Etc.
This was embarrassingly recent, but suffice to say a LOT of lessons were learned. The boat was foreign enough that I accepted too many "explanations" as comfort when they should have been a reason to abort. Failures compounded and voila, we're now 15 hours away from civilization flying a spinnaker through thunderstorms at night and positively hauling ass.
Eventually we got the owner to appreciate our discomfort enough and how over our heads we were to head to safety in Charleston (he'd still just been heading east, which was baffling -- but apparently it is not everyone's first instinct to go to safety when life-threatening failures crop up) but that brought its own perils -- coming into a crowded channel at night without navigation lights isn't advised. We were shining a flashlight onto the sails, but the flashlight would change modes if it wasn't held steadily enough. One of the storms we'd sailed through had killed the owner's phone as well as his phone charger, so the little bits of navigation we had were precious, but necessary coming into shallower coastal waters. A cargo ship coming out of harbor kicked us out of the channel just enough that we ended up grounded and stuck pretty squarely about a half mile away from restaurants, but late enough on a Sunday that there wasn't any other traffic we could hail down. (A radio would have been lovely in that case)
I was sunburnt and heat-stroked enough that despite guzzling water constantly, I hadn't urinated in 24 hours, and though we were in relative calm, the totality of circumstances, I used the last of the dwindling battery on the last usable phone among us to call the coast guard for evacuation. The owner of the boat stayed behind.
To paraphrase Cheryl Strayed -- If you'd asked me at any point in the journey, I was absolutely miserable, but on the whole it was miraculous. Gained a ton of skills. Learned a ton of red flags to look out for. Experienced a lot of firsts, not the least of which included a crash course in celestial navigation. And being 200 miles offshore and awake the whole night during the Perseid meteor shower was absolutely brilliant.
I'm glad you lived to tell the tale, stranger.
Honestly glad my wife was aboard as it lowered my risk threshold enough to get me to want to abort.
Sounds a lot like ocean racing sailboats under normal circumstances.
I quit ocean racing (after about 5 seasons) when I had a sudden realisation that the only part that was any fun in the last 3 days was sitting in the bar after it was over and talking about it. And there were ten times as many non-crew people there enjoying that with us as there were crew on the boat I raced on.
I've been waiting with bated breath since the announcement of Starlink in the hopes that it could knock out the three satellite services I use the most: InReach Mini for text comms and location sharing, XM Radio, and XM Weather.
I'm really looking forward to when this becomes available for individuals and not just businesses. Also really looking forward to 12v Starlink equipment and affordable marine plans.
tc qdisc change dev enp1s0 root netem delay 300ms 200ms loss 10% 80%
Are you sure about that ? According to man tc, it only works on egress.
If I’m reading the docs correctly the satellites will offer SMS service directly so you won’t need an app, you’ll just need your carrier or roaming provider to support it.
This is all incredibly clunky and one of the weakest points of iOS in my view. How can it be so hard to provide a switch that lets me use SMS proactively?
While SMS would be great for low-bandwidth use cases like this, most people don't use it to the point where having contacts accessible with it on the other end would be an issue.
or also any web app.
In a Rails app I recently started working on for a customer I saw many controller actions starting with a call to a method called simulate_delay_for_development. I checked the code and when run in development mode it basically sleeps for a random value between 0.1 and 3.0 seconds.
I'm sure that there are gems for that or proxy servers sitting between the browser and the server, but it's a cheap and effective way to make every developer experience delays with zero installation costs.
Chrome can also throttle the CPU power: https://www.wikihow.com/Throttle-Your-Browser-for-Testing
I don't need to be able to stream Netflix when I'm in the backcountry, it's just that my wife insists I need to be able to get a helicopter if I break my leg.
Now we need app developers to log off their fiber-served wifi when writing messenger apps, and log into a high-latency, low-bandwidth, high-packet-loss network instead so Messages will actually open instead of whatever it's trying to do to upload my location history and download contact pictures...