NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Weird network performance problem



On Mon, 20 Jan 2020 at 01:12, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> Chavdar Ivanov <ci4ic4%gmail.com@localhost> 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.




-- 
----


Home | Main Index | Thread Index | Old Index