But I'm the only one you thinks, that the commit that I linked in one of my previous post, makes no sense?
If the truesize got larger in value, why was the window halved and not doubled?
Actually, it would make more sense, when the user sets a value for example 65536 and then it is internally doubled to 131072 and not the other way around.
I tried to play around with tcp_adv_win_scale but was not able to achieve this goal.
Using a negative number (-1 to -31) will just decrease the window size each time until it is so small that it breaks all TCP connections.
And a positive number (1 to 31) will adjust the window between 50% and 100% (or more?).
I think I will go for 31 (or 0) to disable this overhead calculation.
tcp_adv_win_scale - INTEGER
Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Possible values are [-31, 31], inclusive.
Default: 1
From the documentation... someone has their head screwed on backwards... If you set this parameter to 1, then you'll get bytes/2, if you set it to -1 you'll get bytes - bytes/2 = bytes/2...
I think the docs are wrong... what makes sense to me is
bytes * 2^(x)
I guess someone should look at the code and propose a documentation fix.
Actually I think this is just a case where some programmer is brain damaged...
static inline int tcp_win_from_space(const struct sock *sk, int space)
{
int tcp_adv_win_scale = sock_net(sk)->ipv4.sysctl_tcp_adv_win_scale;
return tcp_adv_win_scale <= 0 ?
(space>>(-tcp_adv_win_scale)) :
space - (space>>tcp_adv_win_scale);
}
basically if you give this a number of bytes, it right shifts by a negative amount which is to say it LEFT shifts the number which is to say it multiplies by 2^x as expected
when it's a negative number, things are weirder... it's doing space - (space * 2^x)
which is to say for very negative values it's basically just space - epsilon... but for -1 it's space - space/2 = space/2
I'm sure this is obviously intuitive once you've devoted your life to banging your head on your desk due to being a kernel programmer
I see it's probably a result of directly going on the basis of how the RFC describes the issue... https://tools.ietf.org/html/rfc1323#page-8 Essentially the true number of bytes is right shifted by the scaling factor to be shoved into the TCP headers, so they focus on that mapping rather than the on of more interest to the kernel which is "what should I do with this number from the TCP header"?
the parameter net.ipv4.tcp_adv_win_scale decides the ratio of receive buffer which is allocated to data vs the buffer which is advertised as the available TCP Window.
so if you set 1 for example, then 1/2 the buffer will be advertised as the available window, if you set 2, then 1/4 of the buffer is advertised as window, if you set -1 then all but 1/2 is advertised as window, if you set -2 all but 1/4... so the code above makes more sense.
...and that sees quite sensible as you need worst case backing store for the data, and an skb carries a lot more than the pure packet data that TCP (naively?) expects, so the trick here is to only advertise a window that can actually fit into the available buffers...
A reverse case of this actually applies ot fq_codel and cake, both allow to specify a worst case memory size for the skb buffer, as on small memory machines that is the critical resource that needs to be carefully managed, especially in the light of GRO/GSO where the old "size buffer by number of packets" approach falls on its back hard ;), but I digress.
Running hynman’s latest February 13th Master build on a r7800 with the performance CPU governor, software offloading enabled, and the below upload only SQM settings on a 940/35 cox cable WAN connection.
Can’t get above 300mbps on piece of cake or layer cake. Best results are with cake or FQ_codel plus simplest or simplest_tbf.
Any of the above posted advanced tweaks worthwhile?
So yes, it does actually make sense. I apologize
But I still don't get why adv_win_scale has a range between -31 0 31.
I guess, using a positive value is more a "safe choice" because the window size will be at least 50% the size of the configured buffers.
But for the negative ones, I don't know, a too high value actually starts to break things.
Read the RedHat tuning guide,most notably it will affect ultra-highspeed lan or lfn's with high amounts of traffic including FORWARDED TRAFFIC. I'm simply experimenting and seeing better results. Setting the rmem/wmem buffers really high results in lots of wifi buffering for immediate testing that is easily seen.
I admit these parameters are still fresh for me since I'm on the windows side of the servers at my local datacenter.
Excuse me, where exactly in that document do they explain that adjusting the buffers/window size on router affect the buffers/window size on a client machine?
When I change the window size on my client machine it is 1:1 reflected and not altered at all by my router.
If the tcp_r/wmem buffers where used for forwarded traffic you would quickly hit the hard limit of all TCP buffers (tcp_mem)
I find these speed tests not-representative of real life usage as they are performed over a wired connection. It is more realistic to do these over wireless (5Ghz and sit next the router for the best case) and all of a sudden, an r7800 cannot get over 200Mbps...
It gets up to low 500’s with speedtest by ookla testing (primarily focused on bandwidth). DSL reports is always a smidge slower.
Any suggested SQM tweaks to squeeze out better latency / bandwidth compared to the basic qdisc + script settings on a r7800? I’m doing pretty well, not having any issues per say, the enemy of good might be better in my case.
Nice! I cannot get those speeds with SQM on my PPPoE connection with WAN VLAN tagging. Looks like I do need to take a serious look into a Raspberry Pi4.
It is wrong to assume that Cisco router HW/SW is anywhere close to a vanilla Linux or a home router. Some of them are not running Linux while others are running a highly customized version of it.
