Насколько я понимаю -это размер буфера передачи, а не окна. Размер окна - это размер подтвержденных данных. Т е если после передачи большого пакета мы передаем маленький и получаем подтверждение этого маленького пакета - это говорит нам, что в следующий момент драйвер не имеет права передавать больше данных чем подтверждено. При этом подтверждения на большой пакет мы не получили - размер окна сужается и как следствие - падает скорость(логическая)
Window scaling allows the use of large (> 64K) TCP windows
in order to support links with high latency or bandwidth.
To make use of them, the send and receive buffer sizes
must be increased. They can be set globally with the net.ipv4.tcp_wmem and net.ipv4.tcp_rmem sysctl
variables, or on individual sockets by using the SO_SNDBUF and SO_RCVBUF socket options with the setsockopt(2) call.
> Размер окна - это размер подтвержденных данных.
да там до фига того, что называется окном :)
> драйвер не имеет права передавать больше данных чем подтверждено.
не совсем так, ну да ладно.
если это имеется в виду, то по-моему, тут ничего не изменишь.
но можно выбрать congestion control: TCP_CONGESTION.
Это -- немного про другое: когда требуется более > 64K окно, надо врубать масштаб, tcp_window_scaling, поскольку на размер окна в заголовке отводится 16-bit целое. При этом, есснно, надо буфера увеличить.
2cvv :
Может, это на мысль наведет (из man 7 tcp):
tcp_adv_win_scale
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. The default is 2.
The socket receive buffer space is shared between
the application and kernel. TCP maintains part of
the buffer as the TCP window, this is the size of
the receive window advertised to the other end.
The rest of the space is used as the "application"
buffer, used to isolate the network from scheduling
and application latencies. The tcp_adv_win_scale
default value of 2 implies that the space used for
the application buffer is one fourth that of the
total.