foreword
In fact, for a long time, I have been thinking about how to use BBR to improve the upload speed of the server to achieve a better experience. For this reason, I adjusted the network parameters of the kernel, and also used various flow control algorithms (fq, fq_pie, cake, fq_codel), I didn’t seem to see any particularly good algorithm. Later, I thought, since various algorithms can’t speed up the speed of my VPS to the country very well, then use the very violent sharp speed. , although not very stable, but at least the speed went up.
So, in order to install Rusui, I tossed the kernel to match the version and Rusui, and the result was obvious: the new kernel was downgraded to the old kernel, causing a bunch of compatibility problems, and then tossing the compatibility of each software…
Finally, after tossing for a long time, under very violent settings, the peak can finally run to 100Mbps, which seems to be a great victory of hardships, but slowly, I found that these thoughts I used to do not seem to be so correct. As I learn more and more, I am now very ashamed of some of my ignorant behavior.
I want to take this here to express some of my current opinions, and also to prevent others from misreading some articles and taking a lot of detours.
Sharp speed violent hair package is perfect?
I believe that the people who can get in touch with Rui Su are all veterans in this circle. In fact, Rui Su has always had a notorious shortcoming: no flow . That’s right, whenever you open the sftp terminal and think that you can happily pull files from the server at a high speed with the help of Sharp Speed, the download speed suddenly drops to 0KB/s before the pull is completed. The previous efforts All in vain, what kind of mood.
Yes, in many cases, we place too much importance on the download speed itself, and forget the crucial transmission stability, a rogue who does not obey the basic rules of Internet transmission, irrespective of the congestion of the backbone network, and indiscriminately sends packets violently. , and will eventually be sanctioned by the backbone routing of major ISPs (directly cut off the connection), this phenomenon is cut off. Morally speaking, it is inherently immoral to use Sharp Speed. It will only continue to increase the already serious congestion of the backbone network for its own benefit, and it is reasonable to be sanctioned.
From this point of view, the side effects of Rui Su are so wide that it is no longer worth using, but in fact, the side effects of Rui Su are not limited to the impact on the backbone network, and are also extremely unfriendly to the users of the server itself. I believe that many of my friends will find that the CPU has high requirements when using Sharp Speed, which is too difficult for friends with limited budgets.
At this point, we can see that evaluating the quality of a blocking algorithm should not only look at its rate, but also its resource occupancy. But there is also a big factor, called traffic efficiency, which is to calculate how many outgoing packets can reach the target host. If all of them can be reached, it is 100%, and it should be as small as possible. Without rigorous testing, only in the daily Internet file pulling test, it can be found that the traffic consumption of Ruisu far exceeds that of algorithms such as cubic, reno, BBR and BBR2. Ruisu has never compromised regardless of the congestion of the route. , crazy to send packages, after all, to pay a painful price. In order to increase the speed by 10%, it is necessary to endure that only about 40% of the traffic is efficient. Such waste is unacceptable.
Therefore, Sharp Speed should have been discarded with the times. A good algorithm should take into account delay jitter (stability), average speed, and resource occupancy (mainly CPU occupancy) in a balanced manner. It is unqualified and cannot bring a good experience to users, and compared with the open-source reno and BBR series algorithms, Ruixu’s algorithm is closed-source, and it is unknown whether it hides private goods .
BBR must be able to fight the future?
I believe that many friends will test back and forth between BBR and BBR2 when testing their VPS, and finally find that the speed of BBR is much faster than that of BBR2, and finally choose to abandon BBR2. In the eyes of many people, BBR2 is really too slow, and it seems that it is slightly faster than reno by 50%, which makes users decisively believe that BBR2 is a semi-finished product, and it is very “rubbish”.
In fact, BBR and Sharp Speed are similar in some aspects, but because BBR pursues fairness more than Sharp Speed, and Smart uses TTL to judge whether the current network is congested, to decide whether to increase the sending bandwidth or vice versa. The route is more friendly, so it is not easy to be blocked, so the interruption of traffic is greatly reduced, so many people choose BBR as the main algorithm.
However, BBR still has relatively high CPU usage requirements (compared to BBR2), and more importantly: BBR is inherently very unfriendly to clients under weak WIFI signals. You can try the 2.4Ghz frequency band transmitted by WiFi. Next (the signal is only 1-2 grids), pull the files on the server with BBR as congestion control. In the case of no network congestion, cubic and reno easily outperform BBR, which limits the use of BBR. This is not what we really want to see.
BBR2 is so slow, how should I choose between BBR and BBR2?
BBR2 solves the performance problem of WiFi. You can think that it is becoming a panacea for the whole scene. It is the most promising to replace the next-generation congestion algorithm of reno. It is a more reasonable and effective solution with low resource overhead, high stability and high stability. The algorithm that uses the redundancy of the available broadband of the backbone network to increase the transmission rate is the algorithm that is truly worthy of recognition.
The delay jitter of BBR2 is currently the best controlled among all algorithms, and it can achieve lower delay. The effective utilization of traffic is also the best, in most cases close to 99%, although the speed is not as fast as BBR, but this is a good thing.
The current ISP routing algorithm is also advancing with the times. More “gentleman” algorithms are welcome, and brainless and violent algorithms are rejected. Currently, BBR2 is currently under the network of telecommunications, China Unicom, and mobile, but it has become a common transmission rate in most scenarios. Algorithms that are fast and not easily interrupted. BBR is no longer so “one-size-fits-all” – at least its advantages in ordinary international routes other than those directly connected to major manufacturers such as Amazon and GCP are slowly shrinking.
BBR2 is also of great help to the improvement of domestic interconnection. Turning on BBR may actually play a role in deterioration, so for domestic machines, if you do not want to use the original cubic and reno protocols, you might as well try BBR2, which may bring Give you more surprises.
At present, the kernel Xanmod specially designed for Linux desktop has adopted the combination of BBR2 algorithm + fq_Pie packet queue to improve the network condition of the client. According to user feedback, the effect is good.
Summarize
The advantages of BBR are slowly being consumed, although the BBR2 branch on Github shows that it is still under development ( Technical/Alpha ), based on the current effect, it has a promising future, and it is likely to become a replacement for reno and reno in the near future. The next generation of the BBR algorithm.
If you want to experience the experience brought by the latest BBR2 algorithm, you can install the xanmod kernel (with its own BBR and BBR2 kernels), and a new CPU scheduling algorithm, but it requires higher memory overhead. If you need a version that only contains BBR2, you can go to Github to compile the kernel yourself.
BBR v2 IPv4 TCP C source code: https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr2.c
How to compile the kernel
RPM department can refer to: https://www.skyzyw.com/article/71.html
DEB system can refer to: https://zgh.im/archives/bbr-v2-installation/
This article is reproduced from: https://leo.moe/daily/bbrv2-introduce.html
This site is for inclusion only, and the copyright belongs to the original author.