From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5718E3BA8E for ; Fri, 13 Oct 2017 05:28:34 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1507886911; bh=gPcb7dsGx6VwpN/RnhE4u2ow2Jc9Is2dBAr1Gz2BFcU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IMHgH03rmDNKl51NWfDA/uu4qI9yvP1g0o7jPPc2aG25rAm9N10EOrHcP1fGs62O6 3a+YXn3QRBMquqqsuyU6A6McDtyIMPlNcbOaSxvSU236GORR+IpXpOAN0lhmOajEwn rQWMA4G1ZdpTnxGEK7oxT06XHyqcGdPnF0gbQxCxZeUMFLnNjLTJixx/U4VYZnCsPt nvIQXzKDlJyo/76upaO2cNNd1QM7UyupxC44xlteZk+u/0vzAaxSc5fsh58W/nvl55 3ujHbrWs0l/cPWj35vvzgjPQt/M85hCwWV7VjFOy3dRlscz+PbLu3rBLLFJZVE+e8F LoGbzsJe71N/g== To: Bob McMahon Cc: Jesper Dangaard Brouer , make-wifi-fast@lists.bufferbloat.net, Johannes Berg In-Reply-To: References: <1507581711.45638427@apps.rackspace.com> <20171011233056.3634daea@redhat.com> <877ew0bwb3.fsf@toke.dk> Date: Fri, 13 Oct 2017 11:28:29 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mv4v9z2a.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] less latency, more filling... for wifi X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 09:28:34 -0000 Bob McMahon writes: > Thanks Toke. Let me look into this. Is there packet loss during your > tests? Can you share the output of the client and server per the error > scenario? Yeah, there's definitely packet loss. > With iperf 2 there is no TCP test exchange rather UDP test information > is derived from packets in flight. The server determines a UDP test is > finished by detecting a negative sequence number in the payload. In > theory, this should separate UDP tests. The server detects a new UDP > stream is by receiving a packet from a new source socket. If the > packet carrying the negative sequence number is lost then summing > across "tests" would be expected (even though not desired) per the > current design and implementation. We intentionally left this as is as > we didn't want to change the startup behavior nor require the network > support TCP connections in order to run a UDP test. Ah, so basically, if the last packet from the client is dropped, the server is not going to notice that the test ended and just keep counting? That would definitely explain the behaviour I'm seeing. So if another test starts from a different source port, the server is still going to count the same totals? That seems kinda odd :) > Since we know UDP is unreliable, we do control both client and server over > ssh pipes, and perform summing in flight per the interval reporting. > Operating system signals are used to kill the server. The iperf sum and > final reports are ignored. Unfortunately, I can't publish this package > with iperf 2 for both technical and licensing reasons. There is some skeleton > code in Python 3.5 with asyncio > that > may be of use. A next step here is to add support for pandas > , and possibly some control chart > techniques (both single and > multivariate > ) for both > regressions and outlier detection. No worries, I already have the setup scripts to handle restarting the server, and I parse the output with Flent. Just wanted to point out this behaviour as it was giving me some very odd results before I started systematically restarting the server... -Toke