Distant Beacons – Part 1 – One Size Sail For Every Ship?

Note – Lighthouse image was used with permission from Ranveig Marie Photography.  Check out her stuff here:  Instagram, Facebook, and Flickr.

This post will serve as part one of a multipart post concerning recent happenings involving client settings, client behavior, what was done to tune a network, and the results thereafter.

Chromebooks have been around for several years now and love them or hate them, they are here to stay.  Chromebooks began as a low cost consumer device but have since crept their way into the enterprise, as well as established a strong foothold in the K12 vertical.  What originally seemed like a cheap compute option, is now available in many different hardware options, many times offering “better than decent” performance for an affordable price.  Don’t be fooled though, there are plenty of Chromebook devices out there that sport less than desirable performance but rep a very attractive price tag.  This initial post explains my desire to get a better understanding of Chromebooks and their behavior on my beloved wireless network.

We currently have tens of thousands of Chromebooks in our Google Domain that are owned and managed by our school district.  We recently reached over 80,000 concurrent wireless devices on our network and ChromeOS serves as a sizable percent of that number,  steadily creeping towards surpassing iOS.  Most of the time everything works great but when there are issues reported, you can bet there is a very good chance the device in question is a Chromebook.  Known issues in the past have been cleared up by Google in relatively short order.  Other times, issues linger on and off, coming and going like the ebb and flow of an ocean tide.  In the recent past our district standardized on a specific manufacturer and model of Chromebook that would be purchased and supported by our department staff.  Many people were brought together to make sure the device met and exceeded our expectation for an exceptional user experience.  Keep in mind there are several thousand other Chromebook devices still on our network which are either legacy holdover or BYOD devices.  Ironically, despite the vast differences, many of the Chromebooks exhibit similar behaviors.  This post will go on to explain my thoughts as to why this may be.

To get a better understanding of Chromebook behavior on wireless networks, I decided to collect data on my own.  This was done to see if I could correlate behaviors with known issues.  I decided to create a simple form on my blog that asked for a few pieces of information easily obtained from a Chromebook with a few commands.  The following information is what I was interested in:

• Chromebook Full Model Name
• ChromeOS Version
• WLAN Adapter Model
• Roam Threshold
• Country

Overall, I was fairly underwhelmed with the response but I did get a handful of responses (thanks to those who contributed).  Out of the responses I did receive there was one very interesting thing that stood out.  The roaming threshold was EXACTLY the same no matter the manufacturer, ChromeOS version (recent or several years old), or WLAN hardware!

Why would 18 (roaming threshold (SNR)) be the threshold that was selected for ALL variations of Chromebooks?  What this means is that if the Chromebook’s Signal to Noise Ratio (the difference between RSSI and noise floor) drops below 18, a roam event could occur because the device deems the signal to be less than optimal.  Those of us who have been in the game for awhile know that the inconsistencies in end-point wireless hardware is the consistency.  Wireless network hardware is not calibrated by the manufacturer.  Wireless network hardware behavior will vary depending on manufacturer, device capabilities, DRIVER VERSION, etc.  In fact, two wireless network adapters made by the same manufacturer using the exact same driver, placed in the exact same model device, will behave differently!  Why would the very intelligent people at Google think that the same, non-adjustable, roaming threshold was best with so many different variables in play?  There may be a good explanation, but so far I have been unable to find it.  Other types of devices (ie. Windows) offer the ability to tune roaming behaviors within advanced driver settings.  To date, ChromeOS does not allow adjustment to these types of settings.

As mentioned earlier, Chromebooks aren’t going anywhere.  They are good devices and fit the K12 environment well due to many factors.  As Chromebooks push further out of the consumer realm and into being an enterprise player, Google may need to adjust their one size fits all wireless settings model.  The massive difference between home use and enterprise use should drive this change unless there is a good reason not to (I’d love to know, Google!).

Future posts will explain more discoveries and how I was able to tame these K12 beasts, with the understanding that bending a network for a single device type is often dangerous.  I like to live dangerously…