Part of the review process for Ars Technica’s first round of mesh testing was talking to the people and companies who build the devices. For established companies like Google or Netgear, you’re never sure who you’ll get—but for startups, who so far are casting long shadows in the Wi-Fi Mesh field, you’re likely to get some one-on-one time with the CEO or founder.

Plume was no exception, and I had a long talk with CEO Fahri Diner. Fahri made it clear from the start that Plume wasn’t about the typical Wi-Fi “ego yardstick”—i.e., setting up a single device super close to the AP in completely ideal conditions and trying to get the biggest number that you can. Real Wi-Fi workloads that real users put their equipment in charge of are an entirely different problem, he said, and that—not the e-peen measuring contest—was the problem Plume was designed to solve.

It’s easy to wave this kind of speech off as clever marketing BS. But I was more inclined to take it at face value than I might otherwise have been, since Plume had just done extremely well in my own testing. I try to make my testing as relevant to real-world conditions as possible—I test in a real house, with real-world distances, interior walls, exterior walls, and furniture in between nodes and client devices. Before using any artificial tools (like iPerf), I even test devices against real protocols (HTTP, SMB/CIFS, and so forth) to make sure they produce equivalent results.

To my surprise—despite his devices having done extremely well in my tests—Fahri waved my results off, too. I was still just testing a single device at a time, and he didn’t think that really mattered. (I'm not going to lie; his words stung.) He explained that Plume was intended to make the entire network fast and reliable, not just one device at a time.

Fahri went on to describe his test facility in Menlo Park, California, where he leased a multi-story residence and set it up, not just with Plume pods, but with the devices of a few competitors. Macbooks were dispersed throughout the house and equipped with a test application designed to mimic workloads like 4K video streaming, VOIP calls, Internet downloads, and Skype sessions. This house is where the rubber meets the road, as Plume tests iterations of its “cloud optimizer” algorithm—if four 4K TV video streams, a 40mbps download, two VOIP calls, and a Skype session won’t all work at once, then test failed.

This sounded like a hell of a setup, so when Fahri invited me to Menlo Park to visit both Plume HQ and the test facility, I grabbed a plane and headed out.

Plume HQ

My first stop after getting to California—unless you count sleeping off the coast-to-coast jet lag—was a morning spent in Plume’s headquarters office. The HQ is a moderately sized open-plan office upstairs from a nail salon. For an avowed small-business type like me, the unassuming setting and restrained chaos inside felt more “real” than giant enterprise campuses tend to.







CEO Fahri Diner met me at the door and barely managed to get through “hello” before making rueful comments about the mistake he’d made launching Plume for iOS only. He said he’s committed to full Android support in February. To make up for the unintentional slight to Android users, Plume is also launching a new, extra-detailed topology view on the Android client first. Fahri only had a little time for chit-chat before leaving to go take care of CEO things, but he handed me over to co-founder and product manager Adam Hotchkiss and engineer Bill McFarland.

After wading through the cubes, I settled in with Adam and Bill for a Powerpoint session. We talked a bit about Plume’s cloud infrastructure—an impressive mix of RabbitMQ message queuing, MQTT sensor telemetry, and the storage and logic modules needed to make sense of it all—and a little about Plume’s upcoming business strategies. Specifically, Plume is partnering with Sagemcom Broadband, a French manufacturer of ISP edge devices (read: cable modems, DSL modems, etc.), to provide ISP-deployed mesh networking solutions. This could be cool, since it addresses one of the standalone Plume setup’s larger weaknesses—the lack of a multiple-ethernet-port “base station” for a wired network—as well as opening up a potentially large revenue stream for Plume itself.





If this model takes off, Adam explained, the vision is for Plume’s control agent software to be natively installed on more and more devices—residential gateways, set-top boxes, and so forth. This also means needing fewer standalone access points. If the set-top box playing movies to your TV can also act as a Wi-Fi access point for your tablet, then why shouldn’t it? All of this talk of residential gateways and set-top boxes drove home a point that I’d already started to suspect: while Plume is proud of its hardware design, it’s not the company’s raison d’etre. What Plume is really excited about is that “cloud optimizer” stuff.

What Plume is really excited about is that “cloud optimizer” stuff.

Powerpoint-and-coffee time concluded, I spent a few minutes with Adam poking at arcane equipment around the labs. The pods aren’t manufactured here, but they are tested and (re)designed here. Two or three rooms in the back were littered with isolation clamshells, ovens, and Wi-Fi tents with home-brewed test mounts and sensors inside. If the Mythbusters ever got back together to debunk Wi-Fi myths, it would look a lot like this.





One of the lab rooms had a bin of Plume pods in various stages of (dis)assembly, so I got treated to a hardware teardown as Adam pointed out the salient features to me. Inside the tiny casing, each Plume pod is a dual-band AC1200 access point/router with a gigabit Ethernet port, a power supply, and some heat spreaders to keep it cool to the touch. I’m not sure what I expected to see, but it definitely wasn’t something this dense. No space is wasted inside a Plume pod.