On Mon, 20 Jan 2020 at 01:12, Greg Troxel <g...@lexort.com> wrote:
>
> Chavdar Ivanov <ci4...@gmail.com> writes:
>
> > From what I can see, the reason is
> >
> > sysctl -w net.inet.tcp.{send|recv}space=131072
> >
> > If I revert to 32768, I get back about the third of the speed.
>
> That is odd. It seems like the sender is not doing well if the window
> is bigger. But, that could mean that queues in your switches are being
> overrun. Until you look at the packet-level loss and retransmission
> behavior you really can't tell what is going on.
I probably haven't explained my observations properly. It works better
with the higher value of these two parameters, as follows:
...
# First run - system boots with the values at 131072, for the test
# I bring them down to the default and start iperf3 -s
# in the bottom tmux pane
..................
# sysctl -w net.inet.tcp.sendspace=32768
net.inet.tcp.sendspace: 131072 -> 32768
# sysctl -w net.inet.tcp.recvspace=32768
net.inet.tcp.recvspace: 131072 -> 32768
....................................................
[ 5] 1.00-2.01 sec 2.65 MBytes 21.9 Mbits/sec
[ 5] 2.01-3.00 sec 2.61 MBytes 22.2 Mbits/sec
[ 5] 3.00-4.01 sec 2.76 MBytes 23.0 Mbits/sec
[ 5] 4.01-5.00 sec 2.57 MBytes 21.6 Mbits/sec
[ 5] 5.00-6.00 sec 2.67 MBytes 22.5 Mbits/sec
[ 5] 6.00-7.00 sec 2.66 MBytes 22.2 Mbits/sec
[ 5] 7.00-8.00 sec 2.65 MBytes 22.3 Mbits/sec
[ 5] 8.00-9.00 sec 2.74 MBytes 23.0 Mbits/sec
[ 5] 9.00-10.01 sec 2.65 MBytes 22.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 26.6 MBytes 22.3 Mbits/sec receiver
-----------------------------------------------------------
# Second run - I up these again to 131072 and restart iperf3 -s;
# (for some reason, if I don't restart, the first test stays at the
previous; the second
# starts to reflect th change in these values; If I restart, the
change is seen first time)
...........
# sysctl -w net.inet.tcp.recvspace=131072
net.inet.tcp.recvspace: 32768 -> 131072
# sysctl -w net.inet.tcp.sendspace=131072
net.inet.tcp.sendspace: 32768 -> 131072
....................................................
[ 5] 2.00-3.00 sec 10.8 MBytes 90.8 Mbits/sec
[ 5] 3.00-4.00 sec 11.0 MBytes 91.9 Mbits/sec
[ 5] 4.00-5.00 sec 10.8 MBytes 90.5 Mbits/sec
[ 5] 5.00-6.00 sec 10.8 MBytes 90.8 Mbits/sec
[ 5] 6.00-7.00 sec 10.2 MBytes 85.4 Mbits/sec
[ 5] 7.00-8.00 sec 11.0 MBytes 92.7 Mbits/sec
[ 5] 8.00-9.00 sec 11.0 MBytes 92.2 Mbits/sec
[ 5] 9.00-10.00 sec 11.0 MBytes 91.9 Mbits/sec
[ 5] 10.00-10.01 sec 104 KBytes 101 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 107 MBytes 89.6 Mbits/sec receiver
......
(the above is through the powerline adapter, so the speeds are lower,
but the slowing down is present no matter where the connection is
coming from; this slowing is present onyly when the client is iperf3
running on W10, and not seen if it comes from NetBSD, Linux or
FreeBSD).
>
> > net.inet.tcp.{send|recv}buf_auto doesn't seem to make any difference.
>
> I am unclear, but it may be that auto is about making adjustments from
> the default, so that could make sense.
I tried the *buf_auto values as they were pointed out as having a
possible connection; I didn't see one in this case.
--
----
