NetEqualizer Bandwidth Controller POE unit a hit with customers

Editors Note:  Just pulled this post off of DSL reports.

NetEqualizer POE units list at $1499 and serve as a great QOS devise for the SOHO small business user.

We’ve ordered 4 of these and deployed 2 so far. They work exactly like the 1U rackmount NE2000 that we have in our NOC, only the form factor is much smaller (about 6x6x1) and they use POE or a DC power supply. I amp clamped one of the units, and it draws about 7 watts.

We have a number of remote APs where we don’t have the physical space and/or power sources (i.e., solar powered) to accommodate the full size Netequalizer. Also, because of our network topology, it makes sense to have these units close to the AP and not at our border. These units are the perfect solution for these locations.

Our service area is mostly in a forest, so have a number of Trango 900 Mhz APs. These units can cut through the trees well, but they only have about 2.5 Mbps available on them (they’re rated at 3 Mbps, but we’ve tested their actual throughput at 2.5 Mbps). We have our customers set for 768k, so it doesn’t take too many Youtube and Netflix streams to kill the performance on these APs. We were using Mikrotiks to throttle the customers (using bursting to give them about 10 minutes @768k, then throttling them to around 300k). While this helped to keep the bandwidth hogs from individually killing the performance, it sometimes made matters worse.

For example, if a customer started downloading some 2 GB file at 10:00pm, it would take them until 1:00pm the next day to finish. As such, they would have disrupted services in the morning and early afternoon. If we had given this customer their full 768k, they would have finished this download before 4:00am and would never have been a disruption.

With the Mikrotik solution, we also had too many times that there was less than 768k available for the next customer, because there were a number of customers locked at 300k tying up much of the bandwidth. So, the customer that was hitting the casual web page was seeing poor performance (as were the hogs). In general, I wasn’t happy with the service we were delivering.

The Netequalizer has resulted in dramatically improved service to our customers. Most of the time, our customers are seeing their full bandwidth. The only time they don’t see it now is when they’re downloading big files. And, when they don’t see full performance, its only for the brief period that the AP is approaching saturation. The available bandwidth is re-evaulated every 2 seconds, so the throttling periods are often brief.

Bottom line to this is that we can deliver significantly more data through the same AP. The customers hitting web pages, checking e-mail, etc. virtually always see full bandwidth, and the hogs don’t impact these customers. Even the hogs see better performance (although that wasn’t one of my priorities).

I didn’t tell any customers that I was deploying the Netequalizers. Without solicitation, I’ve had a number of them comment that the service seems faster lately. It sure is fun to hear unsolicited compliments…

The only tweak of significance I made to the default setup was to change the MOVING_AVG from 8 to 29 (it can be set higher, but you can’t do it in the web interface). This makes it so that the Netequalizer considers someone to be a hog when their average data rate over the last 29 seconds is greater than HOGMIN (which we’ve left at 12,000 – 96 kbps). Given that our customers are set for 768k, this means that they can burst at full rate for a little under 4 seconds before they are considered a hog (approximately 350 KiloBytes of data). The default setting of 8 would allow approximately 1 second at full bandwidth (a little under 100K). By making this change, almost all web pages would never be subject to throttling. It also makes it so that most bandwidth test servers will not see any throttling. The change makes us more at risk that we can peak out the AP (since less customers may be subject to throttling), but we’ve seen that the throttling usually kicks in long before we see that problem.

The only feature I’d like to see in these units is to have a “half duplex” mode. The Netequalizers have separate upload and download pools. This works fine for most ISPs using typical full duplex circuits. However, most hardware that WISPs use are half duplex. So, our Trangos have 2.5 Mbps available TOTAL of upload and download. In order to have the Netequalizer throttle well, I configured it so that the Trangos had 1.9 Mbps down and .6 Mbps up. I would prefer to have a single 2.5 Mbps pool that throttles only when download + upload approaches 2.5 Mbps. If we had this feature, we could move even more data through the Trangos

Related Article