Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Oct 2018 16:19:00 -0700
From:      hiren panchasara <hiren@strugglingcoder.info>
To:        Chenyang Zhong <zhongcy95@gmail.com>
Cc:        transport@freebsd.org
Subject:   Re: TCP RACK performance
Message-ID:  <20181001231900.GA23735@strugglingcoder.info>
In-Reply-To: <CAKS6SJyRk3T5YL72TWC1TtTvOktws9OhHxM7cdzA4RNkcs%2BuVQ@mail.gmail.com>
References:  <CAKS6SJyRk3T5YL72TWC1TtTvOktws9OhHxM7cdzA4RNkcs%2BuVQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--a9msq94+WlNd0NRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Unsure if your questions got answered but this is a more appropriate
list for such questions.

Interesting results. People working on or testing rack don't really use
plain newreno as congestion control afaik. Which might be why they
didn't notice this - is my speculation.

Default Linux uses Cubic as CC. See if switching to cubic helps on
FreeBSD too.

Cheers,
Hiren

On 09/11/18 at 05:41P, Chenyang Zhong wrote:
> Hi,
>=20
> I am really excited to see that @rrs from Netflix is adding TCP RACK
> and High Precision Timer System to the kernel, so I built a kernel
> (r338543) and ran some test.
>=20
> I used the following kernel config, as suggested in commit rS334804.
>=20
> makeoptions WITH_EXTRA_TCP_STACKS=3D1
> options TCPHPTS
>=20
> After booting the new kernel, I loaded the tcp_rack.ko,
> # kldload tcp_rack
>=20
> and checked the sysctl to make sure rack is there.
> # sysctl net.inet.tcp.functions_available
> net.inet.tcp.functions_available:
> Stack                           D Alias                            PCB co=
unt
> freebsd                         * freebsd                          3
> rack                              rack                             0
>=20
> I ran the first test with the default stack. I was running iperf3 over
> a wireless network where rtt was fluctuating but no packet loss. Here
> is a ping result summary. The average and stddev of rtt is relatively
> high.
>=20
> 39 packets transmitted, 39 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev =3D 1.920/40.206/124.094/39.093 ms
>=20
> Here is the iperf3 result of a 30-second benchmark.
>=20
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-30.00  sec   328 MBytes  91.8 Mbits/sec   62             sen=
der
> [  5]   0.00-30.31  sec   328 MBytes  90.9 Mbits/sec                  rec=
eiver
>=20
> Then I switched to the new RACK stack.
> # sysctl net.inet.tcp.functions_default=3Drack
> net.inet.tcp.functions_default: freebsd -> rack
>=20
> There was a 10% - 15% performance loss after running the same iperf3
> benchmark. Also, the number of retransmissions increased dramatically.
>=20
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-30.00  sec   286 MBytes  79.9 Mbits/sec  271             sen=
der
> [  5]   0.00-30.30  sec   286 MBytes  79.0 Mbits/sec                  rec=
eiver
>=20
> I then ran iperf3 on a Linux machine with kernel 4.15, which uses RACK
> by default. I verified that through sysctl:
>=20
> # sysctl net.ipv4.tcp_recovery
> net.ipv4.tcp_recovery =3D 1
>=20
> The iperf3 result showed the same speed with the default freebsd
> stack, and the number of retransmission matched the RACK stack on
> freebsd.
>=20
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-30.00  sec   330 MBytes  92.3 Mbits/sec  270             sen=
der
> [  4]   0.00-30.00  sec   329 MBytes  92.1 Mbits/sec                  rec=
eiver
>=20
> I am not sure whether the performance issue is related to my
> configuration or to the new implementation of RACK on FreeBSD. I am
> glad to offer more information if anyone is interested. Thanks again
> for all the hard work. I cannot wait to see TCP BBR on FreeBSD.
>=20
> Best,
> Chenyang
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

--a9msq94+WlNd0NRk
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAABCgBmBQJbsqthXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4
QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lRF4H/2RAZFDtwfW23FI+j0MvvwX8
k9XxTmhddI/+Zfh34n54ORpyh3hN9GpjxXynIAt5FIudrIqb93vnSutXQHXnlcpf
pKo43J9PGw2VXuQE5KWMhRfmILuo6CcK54TSe3Pcr1RprfwY5D1CTDJU+cvJwfgU
3VENatEvNdmmuQbrmgrFnTQPqCAxtcpUDFAP36wfQXpcojfZVPhoDXMJfQqtn6GT
3Fg+vl8pIrXt+rhdFKnODCrL05WWznTEsdpsSpdshArXvE3od8OCciRvKB2Kb/eK
xetGESOZbaIeVq2cBDkaycbvDS6ZoAEhhCI5pkzqWGcVrs0cYuvW5OmNobUTKxU=
=JEvH
-----END PGP SIGNATURE-----

--a9msq94+WlNd0NRk--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181001231900.GA23735>