Communications satellites are multiplying year by year as more companies vie to create an orbital network that brings high-speed internet to the globe. Ubiquitilink, a new company headed by Nanoracks co-founder Charles Miller, is taking a different tack: reinventing the Earthbound side of the technology stack.
Miller’s intuition, backed by approval and funding from a number of investors and communications giants, is that people are competing to solve the wrong problem in the comsat world. Driving down the cost of satellites isn’t going to create the revolution they hope. Instead, he thinks the way forward lies in completely rebuilding the “user terminal,” usually a ground station or large antenna.
“If you’re focused on bridging the digital divide, say you have to build a thousand satellites and a hundred million user terminals,” he said, “which should you optimize for cost?”
Of course, dropping the price of satellites has plenty of benefits on its own, but he does have a point. What happens when a satellite network is in place to cover most of the planet but the only devices that can access it cost thousands of dollars or have to be in proximity to some subsidized high-tech hub?
There are billions of phones on the planet, he points out, yet only 10 percent of the world has anything like a mobile connection. Serving the hundreds of millions who at any given moment have no signal, he suggests, is a no-brainer. And you’re not going to do it by adding more towers; if that was a valid business proposition, telecoms would have done it years ago.
Instead, Miller’s plan is to outfit phones with a new hardware-software stack that will offer a baseline level of communication whenever a phone would otherwise lapse into “no service.” And he claims it’ll be possible for less than $5 per person.
He was coy about the exact nature of this tech, but I didn’t get the sense that it’s vaporware or anything like that. Miller and his team are seasoned space and telecoms people, and of course you don’t generally launch a satellite to test vaporware.
But Ubiquitilink does have a bird in the air, with testing of their tech set to start next month and two more launches planned. The stack has already been proven on the ground, Miller said, and has garnered serious interest.
“We’ve been in stealth for several years and have signed up 22 partners — 20 are multi-billion-dollar companies,” he said, adding that the latter are mainly communications companies, though he declined to name them. The company has also gotten regulatory clearance to test in five countries, including the U.S.
Miller self-funded the company at the outset, but soon raised a pre-seed round led by Blazar Ventures (and indirectly, telecoms infrastructure standby Neustar). Unshackled Ventures led the seed round, along with RRE Ventures, Rise of the Rest, and One Way Ventures. All told, the company is working with a total $6.5 million, which it will use to finance its launches and tests; once they’ve taken place, it will be safer to dispel a bit of the mystery around the tech.
“Ubiquitilink represents one of the largest opportunities in telecommunications,” Unshackled founding partner Manan Mehta said, calling the company’s team “maniacally focused.”
I’m more than a little interested to find out more about this stealth attempt, three years in the making so far, to rebuild satellite communications from the ground up. Some skepticism is warranted, but the pedigree here is difficult to doubt; we’ll know more once orbital testing commences in the next few months.
This Monday, WireGuard founder and lead developer Jason Donenfeld announced a new WireGuard release for the Windows platform. The release is something of a godsend for administrators hoping to implement WireGuard as a replacement for more traditional end-user VPNs in a business environment, adding several new features that will make their lives easier—or simply make its implementation possible, in environments where it otherwise would not.
If you haven’t heard about WireGuard yet, it’s a relatively new VPN protocol featuring advanced cryptography. It’s implemented from the ground up as an exercise in cleanly written, minimalist, maximally secure and performant code—and it succeeded at those goals well enough to get Linus Torvalds’ own rarely-seen stamp of approval.
Those who are already using WireGuard on Windows will receive an obvious in-app prompting to download and install the new version, which works swimmingly. New users can download WireGuard directly from its website.
The simple “Download Installer” button is aimed at Windows end users, and this probes the user’s system to determine which MSI installer to fetch and execute, based on the user’s system architecture. Sysadmin types may also browse the list of MSIs directly, for use with Active Directory Group Policy automated deployments.
WireGuard for Windows currently supports x86_64, x86 (32-bit), ARM, and ARM64 architectures.
Improved tunnel management for Windows users
Probably the most desperately-sought feature in WireGuard’s windows implementation is the ability for unprivileged users to activate and deactivate WireGuard tunnels via the app’s user interface. Until release 0.3.1, WireGuard has only allowed members of the Administrators group to open the UI, let alone do anything within it.
As of version 0.3.1, that limitation has finally been removed. Unprivileged users may be added to the Windows Builtin group “Network Configuration Operators”—and, once members of that group, if and only if the requisite registry key was added and DWORD value set, they can manage their own tunnel into the corporate LAN.
There’s one more step necessary to enable the limited UI—you need to open regedit, create the key HKLMSOFTWAREWireGuard, then create a DWORD at HKLMSOFTWAREWireGuardLimitedOperatorUI and set it to 1. (Don’t be confused at the lack of HKLMSOFTWAREWireGuard itself—you’ll need to create that, too.)
Otherwise-unprivileged users who’ve been allowed into the WireGuard club can see the tunnels available and start and stop those tunnels. They cannot see the public keys for the tunnels—and more importantly, they can neither add, remove, nor edit those tunnels.
Unprivileged users also cannot exit the WireGuard application itself—they can close the dialog just fine, but the “exit WireGuard” item is missing from the context menu in the system tray. This is because closing the WireGuard app from the system tray doesn’t just get rid of the icon, or even disable the WireGuard tunnel services—it actually uninstalls those services entirely. (The services are automatically reinstalled the next time an Administrator runs the WireGuard app.)
Also new to WireGuard for Windows 0.3.1, multiple tunnels can be simultaneously activated from the GUI. This feature is also registry-gated for now—to use it, you’ll need to create a DWORD at HKLMSoftwareWireGuardMultipleSimultaneousTunnels and set it to 1. Without creating and setting that DWORD, WireGuard for Windows 0.3.1 continues to behave like earlier versions, and activating one tunnel from the GUI will automatically deactivate any others.
For some people, a review of the VanMoof S3 electric bicycle can begin and end with its stunning design. The same goes for its eyebrow-raising $1,999 price tag. Both seem to go hand in hand: this is a pricey electric bike, and it sure looks like one.
Honestly, I’ve never tested a bike that has garnered so much universal drool, and I emphasize that at the top of this review because everything else about the VanMoof X3 ranges from serviceable to questionable. My month-long testing period was never interrupted with serious issues in terms of reliability or battery life, thankfully. Instead, I kept wondering what, exactly, this company was charging a whopping $1,999 for. Usually, each time I had that thought, I’d see yet another passerby make a face, like I was a bikini model in an ’80s beach-romp comedy, and think, “Right. It’s the looks.”
Starting with the automatic gear shifter
The VanMoof caught our eye for reasons other than its aesthetics (though those didn’t hurt). We accepted VanMoof’s offer of a tester bike primarily because of its unique, automatic gear-shifting feature. The bike’s basic sales pitch appeared to be: set it up via an Internet-connected app, then comfortably ride with adjustable, motor-powered pedal assists, made all the niftier by not needing to click your bike’s gear up or down.
Otherwise, VanMoof’s X3 (for heights of 5 to 6.5 feet), much like its slightly larger S3 sibling (for heights of 5 feet, 8 inches to 6 feet, 8 inches), largely resembles other ebikes in terms of features, with enough key differences to merit a full review. Let’s start with that automatic gear-shifting system, which will lead us through various other X3 features and quirks.
How does it work? Though the X3 comes packed with an electric motor, a built-in battery, and even a GSM tracker, its actual sensing of your bike motion begins and ends with a speedometer. This factors hugely into the automatic gear-shifting feature, since it only kicks into gear when you reach various velocity thresholds. The VanMoof app (which isn’t required to use the bike, but highly urged by its manufacturer) lets you pick from three gear-shifting presets: flat, hilly, and custom. Open the “custom” tab, and you’ll get to pick the exact speeds at which the X3 shifts up when accelerating, and a separate list of speeds that will trigger a down-shift when decelerating.
When riding on a flat road using the app’s “flat” preset, this system works exactly as advertised—and in impressive fashion. Gear shifting clicks into place while pedaling with nary a noticeable lurch or noticeably slow reactions by the gear-shifting system. Again, you’re riding a pedal-assist ebike, not a ride that offers automatic throttle—riders still should expect to exert, but the effort needed on a flat road is minimal and steady.
However, I live in a hilly neighborhood of Seattle, where an average ride—either running errands or commuting—includes a mix of steady inclines and declines, along with occasional extreme elevation changes. Before riding, I poked around the VanMoof app in search of any settings that might auto-respond to elevation conditions. I found none. The X3 does not include any sensors like accelerometers or gyroscopes to determine elevation changes. As a result, this velocity-based system struggles to quickly aid riders with the kind of downshifting I’d want the instant I hit a monstrous incline—or a combination of a maintained higher shift and supercharged electric boost.
Instead, before approaching a hill, I found myself needing to park, pull out my phone, wait for the VanMoof app to sync with the bike, and then switch my riding profile from “flat” to “hilly.” Users must deal with the same obnoxious stop-and-refresh requirement whenever adjusting the amount of pedal-assist boost the bike’s motor offers (offered in a number range, from 1 to 4). I’ve never tested an ebike that makes users park to adjust a pedal-assist system, and this particularly annoyed me with the VanMoof.
I’m a relatively athletic rider who likes to mix up pedal assistance on ebikes: I start with less assist, while I’m feeling fresh and wanting some exercise, then crank up the assist to either tackle major hills or ease the final leg of a ride. The VanMoof takes me out of that use case, and between that and its stupidity about hills, I found myself leaving it at its maximum-assist setting at all times, lest I be caught in a pickle.
Honk and boost
The handlebars include two buttons, though neither offers a shortcut to adjust the gear-shifting system or pedal-assist level. While riding, the left-hand button activates a “horn,” which plays a digital sound effect from a built-in speaker, and the right-hand button toggles “boost” mode. This delivers an extra jolt of battery-boosted pedaling strength in a pinch—like, say, when you need to climb a hill. While this button is held down, the engine will drive additional pedal assistance.
Both of these buttons underwhelm, however. The horn can be customized with one of three prebuilt sound effects available in the VanMoof app, but there’s no getting around how weakly this sound effect carries in an average ride through traffic. Should safety be a priority for your commute, you’ll want to attach a physical higher-frequency bell as soon as possible.
Meanwhile, the boost button seems to offer a predefined boost above your current pedal-assist level, as opposed to a universal maximum. Meaning: if you’re riding with a mild pedal-assist level (2 out of 4) and approach an extreme hill, the boost button will effectively get your pedal-assist level to a 3. For some of the extreme Seattle hills I’ve faced, that’s not enough boost. In this case, you’ll need to get the app out, switch the pedal-assist to the max of 4, then use the boost button to throttle your pedaling up to a “5”-ranked boost.
To be clear: that boost button is not an automatic, engine-driven throttle. You can’t press the button and expect the bike to surge forward automatically. Worse, holding the boost button does not immediately up-shift the gear system. When I wanted to rapidly accelerate from a dead stop to cross a busy traffic intersection, the VanMoof could feel dangerously sleepy, even with the boost button held.
Battery and lock
After coming to terms with those issues, I settled on an ideal VanMoof X3 riding setup: the “flat” gear-shifting preset, the maximum “4” pedal-assist setting, and a serious reliance on that boost button whenever I reached a moderate hill. (I still had to switch the gear-shifting preset whenever I reached a particularly steep hill, then switched it back to “flat” once I returned to reasonable inclines and declines.)
With those settings straightened out, I found that the bike primarily worked as advertised. You can expect an ample amount of pedal assistance with either the “3” or “4” preset enabled, and between those and the boost button, I never found myself needing to stand up and exert in order to smoothly accelerate to a speed of roughly 20mph.
I never ran into issues with battery life dramatically depleting, and VanMoof’s estimate of 37 miles on a full 504MWh battery (at level-4 assistance, with daytime running lights) comes close to matching my own testing experience, maxing out at roughly 32 miles. In good news, should the bike’s battery entirely deplete, its 41-pound body doesn’t feel quite that heavy to ride with zero assistance—which I learned after riding for two blocks with the motor off.
Yes, you’ll feel the difference without power, but it’s good to know that the bike doesn’t lock up without power. The system will seize up if the built-in lock is engaged, of course. And if you’re particularly protective about your pricey bike, you’ll appreciate the almost feather-touch sensitivity of the X3 when its built-in lock is enabled (which can either be engaged through the app or by tapping the “lock” button on the side of the back wheel). Move the bike at all, and a loud, high-frequency speaker will aggressively chirp; keep trying to move the bike, and that noise will get louder and more consistent. Personally, I seriously wish the settings menu included a toggle for a much softer initial chirp—like, say, when you have the bike parked at a busy rack, where it will likely be innocently jostled. Like, count to five before freaking out, VanMoof.
The built-in GSM tracker offers all of the built-in overkill tracking you might want for a pricey bike, should someone decide to lift your screeching bike off the ground and load it into the back of a van. Burglars would apparently need to saw the bike in half to pick that tracker out of it. You can also pay VanMoof an additional theft-proof fee to get a 100-percent free bike from the company ($350 for a three-year guarantee), should some scofflaw successfully steal yours.
Sadly, the built-in battery is just as wedged into the bike’s body as the GSM tracker is. Any X3 recharging requires running a cord from a wall outlet to the bike itself—plus, you can’t stash and swap a backup battery for a particularly long ride. The included power brick’s cables max out at around 108 inches, which isn’t long enough to run from my front door’s nearest power outlet to the safest place that I can park my bike outside. A full charge takes about four hours, while a single hour will recharge to about 50 percent.
In an embargoed presentation Friday morning, Intel’s Chief Performance Strategist Ryan Shrout walked a group of tech journalists through a presentation aimed at taking AMD’s Zen 2 (Ryzen 4000 series) laptop CPUs down a peg.
Intel’s newest laptop CPU design, Tiger Lake, is a genuinely compelling release—but it comes on the heels of some crushing upsets in that space, leaving Intel looking for an angle to prevent hemorrhaging market share to its rival. Early Tiger Lake systems performed incredibly well—but they were configured for a 28W cTDP, instead of the far more common 15W TDP seen in production laptop systems—and reviewers were barred from testing battery life.
This left reviewers like yours truly comparing Intel’s i7-1185G7 at 28W cTDP to AMD Ryzen 7 systems at half the power consumption—and although Tiger Lake did come out generally on top, the power discrepancy kept it from being a conclusive or crushing blow to AMD’s increasing market share with the OEM vendors who are actually buying laptop CPUs in the first place.
Enter the battery
Intel’s original Tiger Lake launch presentations sought to draw attention to on-battery versus off-battery discrepancies in AMD’s performance, but those attempts mostly went unheard. Shrout’s presentation Friday was an attempt to tell that story again, this time with enough additional information to get people fired up.
We can see this discrepancy between on-battery and off-battery performance easily in the PCMark 10 Applications benchmark and also in many of Intel’s RUGs—scripted workloads based around production applications, which the company calls “Realistic Usage Guides.” However, the same discrepancy between on- and off-battery performance isn’t visible in more commonly used industry benchmarks, such as Cinebench, PassMark, or Geekbench.
Intel’s engineering team displays the reason why we don’t see the discrepancy in Cinebench in the last image of the gallery above—in Intel’s testing, the Ryzen 4000 CPUs didn’t ramp up power and voltage to their maximum state until somewhere between eight and 11 seconds after heavy-duty workloads began.
We were able to confirm Intel’s findings over the weekend, working with an Acer Swift 3 SF314-42 laptop (with a Ryzen 7 4700u CPU) and an MSI Prestige 14 Evo laptop (with a Core i7-1185G7). In the charts above, we repeatedly compress small chunks of the Linux 7.3 kernel source and graph throughput over time on each CPU.
The 4-core/8-thread i7-1185G7 easily outperforms the 8-core/8-thread Ryzen 7 4700u in both single and quad-thread workloads, even after the Ryzen 7 4700u belatedly jumps to its full performance around the 12-second mark. In the unlimited workload, where the Ryzen 7 is allowed to flex its full octa-core muscle, things are much closer—and the 4700u even ekes out a narrow win in the last four seconds.
There are a few things we need to point out here, though. First and most obviously—Intel is 100 percent correct in its claims that AMD’s Zen 2 laptop CPUs delay ramping power and voltage up to their maximum states. This causes a sharp, corresponding, and decreased performance during those first few seconds.
We reached out to AMD representatives for comment on this design decision. Although AMD representatives asked further questions about our observations, we have not yet received a response for the record at press time.
The devil is in the details—so is the heat
But Intel is still playing games with its own power consumption. In the above screenshot, we can see the MSI Prestige Evo 14 with Core i7-1185G7 during a Cinebench R23 run. We haven’t had this laptop for long enough to fully review it—and particularly, to review its battery life, which we’ve been very curious about since being forbidden to test that stat in two earlier i7-1185G7 systems.
But we can see that—rather than dial the i7-1185G7’s cTDP down to something approximating the typical Ryzen 7 4000 cTDP of 15W, as widely expected—MSI has in this laptop chosen to dial it up even further than what we saw in earlier prototypes. This production i7-1185G7 system has a variable PL1 which hits as high as 36W during the course of a Cinebench R23 run—in addition to its PL2 of 51W, which is unchanged from the prototypes.
During this Cinebench R23 run, the laptop spent its first 10 to 15 seconds running at the full PL2 power limit of 51W, with temperatures up to a blistering 98°C. After that initial, extremely high-performance, power, and heat generating burst, the CPU dropped down to sustain an average power consumption of 34W. By contrast, an 8 core / 16 thread Ryzen 7 Pro 4750U—at cTDP up of 25W—consumed an average of 27.9W, with a high of 29.9W.
While we’re veering away from the CPUs themselves and into laptop-design territory, it’s perhaps worth noting that system-fan activity was also significantly different between the MSI Prestige 14 Evo—which reached nearly gaming-laptop levels of fan noise almost immediately—and the HP EliteBook, which took more than a minute to ramp its fans up to max and remained much quieter than the MSI throughout the run.
The battle continues
While Intel didn’t specifically tell us what conclusions we should draw from the performance delay in Zen 2 laptop CPUs versus the instant-on performance from Tiger Lake, the company was clearly hoping for something in between “AMD is gaming the benchmarks” and “it turns out, Intel was the winner all along.”
We don’t think there are any such cut-and-dried conclusions to draw here. Intel’s findings regarding the slow performance ramp of the AMD Zen 2 laptop CPUs is, obviously, correct in the facts—we had no trouble confirming it, and it does explain why many of Intel’s preferred benchmarking techniques show larger performance deltas in favor of Team Blue than the more widely used industry benchmarks like Cinebench, PassMark, and so forth.
But this ignores the greater efficiency of the AMD systems, above and beyond the delayed shift to maximum performance (and battery consumption) states in the CPU. When we run Cinebench R23 for five full minutes, a Ryzen 7 Pro 4750u system renders more scenes than the Intel i7-1185G7, and it does so with less total power consumed. There’s no clever trick to explain that away.
We also believe there’s a tuning argument to be made on both sides. Intel’s more rapid shift to the highest performance state carries some real-world benefits with it, but we’re not certain they’re as compelling as the charts make them seem. In practical terms, we’ve spent quite some time now with both Zen 2 and Tiger Lake laptops—and the Tiger Lake systems don’t really feel faster in terms of a seat-of-the-pants subjective experience. This argues strongly that there frequently isn’t much point in ramping up CPU power profiles that quickly—if the human piloting the system doesn’t notice the latency improvement, it’s probably better to conserve the battery instead.
The best news for consumers, we suspect, is that the “which system is better” argument is so difficult to conclusively answer in the first place. This level of competition means neither team gets to rest on its laurels, and consumers are less likely to end up buying systems nobody would want, if fully informed about the differences.