Good afternoon to all habra users.
I constantly read articles on Habré about the development of this or that functionality on the "Malinka". I decided to share my work here.
Background
I work in a company that provides cable TV and Internet access services. And, as is the case in such companies, I periodically hear complaints about the inconsistency of the tariff plan with the one stated in the contract. Now the user complains about the low speed "over the cable", then about the high pings of certain services, sometimes about the complete absence of the Internet at a certain time of the day. Often, such complaints end up in the pool of applications, according to which one of the employees with a working laptop, on which all measurements are made, is sent to the site. And, often, it turns out that everything is in order with speed. And the low speed is actually on a mobile phone, via wi-fi, on the balcony. Well, or something like that.
Unfortunately, it is impossible to go to the subscriber for example at 21:37, when he has the lowest speeds. Still, the working day of employees is limited. Replacing the router has no effect. the frequency range for wi-fi in our country is deplorably cluttered.
For reference - the state provider in the Republic of Belarus forcibly turns on wi-fi on all devices provided for use and broadcasts the SSID ByFly from each device. Even if the subscriber does not have an Internet service, but only a home phone. This is done for additional sales. You can buy a card of this operator in a stall, connect to any point with the name ByFly and, by entering data from the card, receive Internet services. Taking into account almost 100% coverage of cities and significant coverage of the private sector and rural settlements, finding a connection point is not a problem.
Observing our external communication channels shows that there is a given bandwidth reserve. And subscribers in total do not consume the available channels, even during rush hour. With this we are all very serious. The use of different services and different servers for measuring speed has led to interesting results. It turns out that not all services are equally useful ... Especially in the evenings. And you shouldn't trust them unambiguously. Many operators of the same Ookla network do not have wide communication channels, or they work end-to-end. This means that it is often almost impossible to get an honest result in the evening. And the highways are sinning. For example, attempts to measure speed in Japan show extremely deplorable results ...
Primary solution
Photo for illustrative purposes
Two speed control servers were deployed. The first is LibreSpeed , the second is the Speedtest from OOKLA . The performance of both services was compared. We decided to stop at Ookla. up to 90% of subscribers use this particular service.
Next, instructions were written for users and employees on how to measure the speed inside the network and outside. Those. when starting the test, the speed is measured within the network by default. The server is located at our head station, and the Ookla solution, by default, selects the closest server to the subscriber. Thus, we check the operation of our own data transmission network.
To measure the speed within the country (we have a separate network for telecom operators, which unites all operators and the main data centers within the country), you need to select a provider within the country and re-measure. We have empirically identified several servers that give more or less stable results at any time of the day and prescribed them as recommended in the instructions.
Well, similar actions for external communication channels. We found large operators with large channels on speedtest servers and wrote them in recommendations (forgive Moskva - Rostelecom and Riga - Baltcom, but I will recommend these nodes to get adequate numbers. Personally, I received up to ~ 870 megabits from these servers during peak hours).
Why, you ask, are such difficulties? Everything is very simple. We have received a fairly convenient tool that, in capable hands, allows us to determine: are there any problems in our networks, are there problems in the republican network, are there problems with the trunk. If a person complains about a low download speed from some service, we can measure the speed of the subscriber's channel and then compare with what he receives from the service. And it is argued to show that we are honestly highlighting the channel prescribed in the contract. And we can also explain the possible reasons for such a difference in speed.
Secondary solution
The question of the speed drop in the evenings / during the day remains open. How to do all the same without being at the subscriber's home? Take a cheap single board with a gigabit network and make a so-called probe out of it. The device should take measurements of speed through the cable at a specified time interval. The solution should be open source, as unpretentious as possible, with a convenient admin panel for viewing the measurement results. The device should be as cheap as possible so that it can be easily replaced and left with the subscriber for n days without fear.
Implementation
BananaPI (model M1) was taken as a basis. There are actually two reasons for choosing.
- Gigabit port.
- He was just lying in the nightstand.
Next, it was decided to use the speedtest-cli python client for the Speedtest by Ookla service as a backend for measuring speed. Pythonping library for measuring ping speed. Well, and php for the admin area. For the sake of convenience, I used bootstrap .
Due to the fact that the raspberry resources are not rubber, a bunch of nginx + php-fpm + sqlite3 was used. We wanted to abandon MySQL because of its heaviness and redundancy. Anticipating a question regarding Iperf. It had to be abandoned due to the impossibility of using it in directions other than local ones.
Initially I followed the path of many on this site. Modified the speedtest-cli client. But then, after a little reflection, he abandoned the idea. I wrote my own worker that uses the capabilities of the original client.
To analyze pings, I simply wrote a separate handler. We take the average value by measurement. Pingovalka knows both an ip address and a domain name.
I did not achieve asynchronous work. She is not particularly needed in this case.
The admin panel for evaluating the results turned out to be quite minimalistic.
Fig. Updating the Speedtest Server List
That's it. The idea was realized on the knee, in free time from work. The field tests have not yet begun. But we plan to launch prototypes in the near future. You can use both providers there and the clients of providers. Nobody bothers to put measurements at home around the clock. The only thing to remember is that if you are actively surfing the net or downloading something, then the measurement will turn out to be lower than the real one. So, ideally, the probe should be left on the network as the only traffic consumer.
PS: please do not kick for the quality of the code. I am self taught with no experience. Source code on GitHub . The criticism is accepted.