On Fri, 2016-12-02 at 23:40 +0100, Steinar H. Gunderson wrote: > On Fri, Dec 02, 2016 at 05:22:23PM -0500, Neal Cardwell wrote: > > Of course, if we find important use cases that don't work with BBR, we will > > see what we can do to make BBR work well with them. > > I have one thing that I _wonder_ if could be BBR's fault: I run backup over > SSH. (That would be tar + gzip + ssh.) The first full backup after I rolled > out BBR on the server (the one sending the data) suddenly was very slow > (~50 Mbit/sec); there was plenty of free I/O, and neither tar nor gzip > (well, pigz) used a full core. My only remaining explanation would be that > somehow, BBR didn't deal well with the irregular stream of data coming from > tar. (A wget between the same machines at the same time gave 6-700 Mbit/sec.) > > I will not really blame BBR here, since I didn't take a tcpdump or have time > to otherwise debug properly (short of eliminating the other things I already > mentioned); most likely, it's something else. But if you've ever heard of > others with similar issues, consider this a second report. :-) > > /* Steinar */
It would be interesting to get the chrono stats for the TCP flow, with an updated ss/iproute2 command and the kernel patches : efd90174167530c67a54273fd5d8369c87f9bd32 tcp: export sender limits chronographs to TCP_INFO b0f71bd3e190df827d25d7f19bf09037567f14b7 tcp: instrument how long TCP is limited by insufficient send buffer 5615f88614a47d2b802e1d14d31b623696109276 tcp: instrument how long TCP is limited by receive window 0f87230d1a6c253681550c6064715d06a32be73d tcp: instrument how long TCP is busy sending 05b055e89121394058c75dc354e9a46e1e765579 tcp: instrument tcp sender limits chronographs _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm