On Monday, we released version 1.4 of NetBeez. This update includes a new workspace dedicated to the monitoring of WiFi networks called the WiFi tab. Under the WiFi tab, users can define which networks will be monitored by the sensors. For each SSID configured, the dashboard displays the status and performance measurements detected by the sensors.
Performance measurements from each WiFi sensor include:
- Signal strength (dBm) – The WiFi signal strength value is expressed in decibels in relation to a milliwatt.
- Link quality (%) – This value expresses in percentage the link quality of the WiFi connection; the link quality is calculated by the WiFi network card installed on the sensors.
- Bit rate (Mbps) – This is the data speed established between the access point and the sensor.
- BSSID (MAC) – The MAC address of the access point that the WiFi sensor is connected.
- Channel (GHz) – The frequency used by the access point and the sensor to communicate.
- Interface speed (bps) – The real-time bps transmitted and received on the WiFi interface of the sensor.
This information was already available in previous software versions of NetBeez, however, such data was only available on a per-agent basis, under each agent’s detailed view. The WiFi measurements from all sensors were not aggregated on a per-SSID basis. This was making it very cumbersome and time-consuming to compare data from multiple monitoring sensors when troubleshooting WiFi performance issues. In 1.4, it’s now possible to compare multiple data points under the WiFi tab.
Let’s imagine that you have 50 WiFi sensors deployed in different areas of an enterprise network. In the WiFi tab, users can see the performance of each sensor highlighted in a bar chart that groups sensors, based on signal strength, link quality, and bit rate, with similar performance. The goal of this section is, for example, to quickly identify the WiFi sensors that have weak signal strength and poor link quality.
This release also includes support for WiFi incidents. Similar to agents and targets incidents, WiFi incidents are configured by setting thresholds for each test type (ping, DNS, HTTP, and traceroute). Each threshold specifies the percentage of tests deemed necessary to trigger alerts and open a WiFi incident.
Let’s suppose that you have the ping threshold set to 90% and that each of the 50 WiFi sensors monitoring a specific SSID is running 2 ping tests. In this scenario, there are a total of 100 ping tests. If 90 or more ping tests trigger a performance alert, then a WiFi incident will be created.
WiFi was not the only new feature in NetBeez 1.4 release – it’s now possible to run speedtest and VoIP tests straight from the Ad-Hoc Testing tab, without having to create scheduled tests. This provides an efficient method to quickly verify Internet speed and Voice-over-IP performance between any two agents managed by the dashboard.
As you can see in the previous screenshot, NetBeez now supports two new types of speed tests:
- NDT – As I originally covered in a previous blog post about NDT, this test runs a download and upload speed test very similar to the Ookla one, but to a different set of servers sponsored by the measurement lab (M-Lab). It’s a good alternative to the existing Ookla speedtest.
- Fast.com – Is a download speed to the NetFlix CDN network to verify the performance of NetFlix streaming. This feature is particularly useful to Internet Service Providers interested in measuring the home subscriber end-user experience.
The last major improvement of the 1.4 release is the containerization of the NetBeez server. This improvement only pertains to the backend, so the average user may not be as interested in this upgrade. Still, it’s a great milestone for the development team to successfully manage the build and release process. Containers make it much easier and more simple to release new updates while making servers more scalable. If you want to read more about this new release, check out the release notes of 1.4.
