From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2A5183B29D; Sat, 3 Jun 2023 14:56:13 -0400 (EDT) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 364231B31E; Sat, 3 Jun 2023 11:56:12 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 364231B31E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1685818572; bh=oFh9jxhdAv+hSlErS8/+imAEI/aDWJgFC7vRlJIbUD8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RwYCha9tjAFlatQaTQm6t8fMYvEuuPjS22quijh9EM5as/s0o68ONd+EW3FAKc6zT zzmhhOt+BdLiGd5avS3QzaPZuPrUiyIgsnWKR+M1SP5ddpJ5GgSakikXKPk7+1SGlt w3Q2o97P2M8g0NRQrw44GrbhjB5R4hn/zsYQvaWU= MIME-Version: 1.0 Date: Sat, 03 Jun 2023 11:56:12 -0700 From: rjmcmahon To: Dave Taht Cc: bloat , Rpm In-Reply-To: References: Message-ID: <709fd354372c370233f4b4eb33bab216@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] [Rpm] receive window bug fix X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2023 18:56:13 -0000 > these folk do good work, and I loved the graphs > > https://blog.cloudflare.com/unbounded-memory-usage-by-tcp-for-receive-buffers-and-how-we-fixed-it/ Very cool. Thanks for sharing. I've been considering adding stress tests to iperf 2. Looks like Cloudfare has at least two Small reads & writes with short delay to stress receive window processing per At the sending host, run a TCP program with an infinite loop, sending 1500B packets, with a 1 ms delay between each send. At the receiving host, run a TCP program with an infinite loop, reading 1B at a time, with a 1 ms delay between each read. And then, rx buffer limit tests, from https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/ reads as fast as it can, for five seconds this is called fast mode, opens up the window calculates 5% of the high watermark of the bytes reader during any previous one second for each second of the next 15 seconds: this is called slow mode reads that 5% number of bytes, then stops reading sleeps for the remainder of that particular second most of the second consists of no reading at all steps 1-3 are repeated in a loop three times, so the entire run is 60 seconds This has the effect of highlighting any issues in the handling of packets when the buffers repeatedly hit the limit. Curious about any other traffic scenarios driven by socket read/write behaviors that could be useful. Or any others that might apply to WiFi aggregation. Then, if there is a way to generalize these types of send/read/delay graphs with a parametric command line? Bob