Good afternoon to all habra-users.
I constantly read articles on Habré about the development of this or that functionality on the "raspberry". Decided to share my experience here.
prehistory
I work for a company that provides cable TV and Internet access. And, as it happens in such companies, I periodically hear complaints about the discrepancy between the tariff plan and the one stated in the contract. Either 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 certain times of the day. Often, such complaints fall into the pool of applications, according to which one of the employees goes “to the place” with a working laptop, on which all measurements are made. And, often, it turns out that everything is in order with the speed. And the low speed is actually on a mobile phone, via wi-fi, on a balcony. Well, or something similar.
Unfortunately, it is impossible to go to the subscriber, for example, at 21:37, when he has the lowest speeds. Still, the working hours of employees are limited. Replacing the router has no effect, because. the frequency range for wi-fi in our country is deplorably littered.
For your information: - the state provider in the Republic of Belarus forcibly turns on wi-fi on all devices provided for use and broadcasts ByFly SSID from each device. Even if the subscriber does not have Internet service, but only a home phone. This was 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. With almost 100% coverage of cities and significant coverage of the private sector and rural areas, finding a connection point is not a problem.
Monitoring of our external communication channels shows that there is a given bandwidth headroom. And subscribers in total do not consume available channels even during rush hour. We are taking this very seriously. The use of different services and different speed measurement servers led to interesting results. It turns out that not all services are equally useful ... Especially in the evenings. And you should not unequivocally trust them. Many operators of the same Ookla network do not have wide communication channels, or work back to back. And this means that in the evening it is often almost impossible to get an honest result. Yes, and highways are sinning. For example, attempts to measure speed to Japan show extremely deplorable results ...
Primary Decision
The photo is for illustrative purposes.
Two speed control servers were deployed. The first one is second - . The performance of both services was compared. Still, they decided to stop at Ookla. up to 90% of subscribers use this particular service.
Further, instructions were written for users and employees on how to measure the speed inside the network and out. Those. when you run the test, by default, the speed within the network is measured. The server is located at our headend, and the Ookla solution by default selects the closest server to the subscriber. In this way, we check the operation of our own data transmission network.
To measure speed within the country (we have a separate network for telecom operators, which unites all operators and 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 the recommendations (forgive me "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, such difficulties? Everything is very simple. We have received a fairly convenient tool that, in capable hands, allows us to determine whether there are any problems in our networks, whether there are any problems in the republican network, whether there are any problems with the backbone. If a person complains about the low download speed from some service, we can measure the speed of the subscriber's channel and then compare it with what he receives from the service. And it is reasonable to show that we honestly single out the channel prescribed in the contract. And we can also explain the possible reasons for such a difference in speeds.
secondary solution
The question of 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 must take speed measurements over the cable at a specified time interval. The solution should be open source, as unpretentious as possible, with a convenient admin panel for viewing 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 just lay in the bedside table.
Next, it was decided to use the python client for the Speedtest by Ookla service as a backend for measuring speed. library to measure ping speed. Well, and php for the admin. For ease of perception, I used .
Due to the fact that the raspberry resources are not rubber, the nginx + php-fpm + sqlite3 bundle was used. I wanted to abandon MySQL because of its heaviness and redundancy. I foresee a question concerning Iperf. It had to be abandoned due to the impossibility of its use in directions other than local ones.
Initially went the way of many on this site. Modified the speedtest-cli client. But then, after a little reflection, he abandoned this idea. I wrote my own worker, which uses the capabilities of the original client.
To analyze pings, I simply wrote a separate handler. We take the average value of the measurement. Pingovalka knows how to ip address and domain name.
Asynchronous work did not achieve. It is not really needed in this case.
The admin panel for evaluating the results turned out to be quite minimalistic.
Fig. The main admin window with test results
Fig. Test settings
Fig. Updating the list of Speedtest servers
That's actually all. The idea was implemented on the knee, in my spare time. Field trials have not yet begun. But we plan to launch prototypes in the near future. It is possible to use both to providers there and to clients of providers. No one bothers to put measurements at home around the clock. The only thing to remember is that if you actively surf the net or download something, then the measurement will turn out to be lower than the real one. So, ideally, you need to leave the probe on the network as the only traffic consumer.
PS: for the quality of the code, please do not kick. I am self taught with no experience. Source code on . Criticism is accepted.
Source: habr.com