09Feb17 [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 09 Feb 2017 Hangout Notes ======

  * rrs@ mentions that they now have a "black box recorder" which is done by jtl@.  This uses a set probes to collect data over time.  It collects data in pcap form t so that you can look at it tcpdump.  It can either stream data or dump data following a signal.  jtl@ will put up a review soonish.  gnn@ wonders if much can be done with DTrace.  

  * BBR has been handed over to the production team and will be off by default in the NF kernels, but can be turned on via a socket option.  The performance is looking good in their testing.  rrs@ wants to get this into their transport lab for testing.  One issue remains the CPU utilization of the callout system.  rrs@ will move BBR to using the pacing infrastructure as it has a lower CPU overhead than the callout system.

  * People need to review https://reviews.freebsd.org/D9356 which glebius has put up for review.  This splits listen sockets from data transport sockets.

  * rrs@ points out that if you are always in sequence and not having loss you will grow your window but will never tell the peer.  He says he will make a patch for review.

  * hiren@ is working with lstewart@ on what's broken with the fast recovery fix.  The fix from a few months ago to not revert to 1MSS seems to result in a higher level of retransmits.

  * gnn@ asks if tuexen@ is ready to push his changes to tcp-testsuite

  * gnn@ will kick off a conversation with Neal at Google and tuexen@ about upstreaming to the main repo

  * rstone@ asks for review of https://reviews.freebsd.org/D9465 . bz@ suggests taking some of the UTO spares.

  * tuexen@ asks what happens in IPv6 when we process a "packet too big" ICMP error.  On IPv4 the host cache is updated.  bz@ will send the things he knows about this directly to tuexen@

  * rstone@ points out that clearing the SRTT after 3 retransmits makes debugging harder.  rstone@ will put up phabricator on this topic.

  * tuexen@ asks about this review https://reviews.freebsd.org/D9475 which addresses an issue with very small receive buffers.