From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id EB6AE200B33 for ; Sat, 7 Apr 2012 11:50:26 -0700 (PDT) Received: by werm1 with SMTP id m1so3682730wer.16 for ; Sat, 07 Apr 2012 11:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y55uo0igyY4NnEGDeNPpYlvxqQ4chbHNoznMpnRDnEg=; b=owZKVDhn1VRncKN2/ItTO0qTz5seA/COmE1vOv4Z/Mg8qzJXhVLeeuoUYD2WHxN4zw T4AHLOfCtH/3Rdch5lTWCeODii3OIfDNRgARVN89T0TvnNO0OL7iAcUvdUMIUvWeOU+z kXq2HHQbofFlmw2Fe+nFB3o5A5FWTG5m1F9WGOqsOhTjF/gb56QgnMo2c0meIuvMjKZL M/uZ+IRVvpP2LZOpHKyAkZRpwasnNFeu3dQ1ujV9ydDCZrG//kLlhaVe0VxX/w3FnxWX PRW3Yz6z8UGii6FlR7L/FTiL0OjxR02tzIth7gti6cUYyz0UBybTbZMbYTnT5065qNTU MSlw== MIME-Version: 1.0 Received: by 10.216.138.135 with SMTP id a7mr1212170wej.19.1333824624955; Sat, 07 Apr 2012 11:50:24 -0700 (PDT) Received: by 10.223.127.194 with HTTP; Sat, 7 Apr 2012 11:50:24 -0700 (PDT) In-Reply-To: <20120407181034.GD21452@uio.no> References: <20120406213725.GA12641@uio.no> <20120406222138.GB12641@uio.no> <1333811327.30705.4.camel@edumazet-laptop> <20120407153548.GC21452@uio.no> <20120407181034.GD21452@uio.no> Date: Sat, 7 Apr 2012 11:50:24 -0700 Message-ID: From: Dave Taht To: "Steinar H. Gunderson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Best practices for paced TCP on Linux? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 18:50:27 -0000 Steinar: Judging from these results it sounds like you should try limiting the send window. I don't know what the right number is, or what the current calculation for what percentage of this is used for window related buffering, (anyone?) but reducing the defaults by a lot for your tcp based video servers seems like a good idea. to do that, edit /etc/sysctl.conf, add or change the line for net.core.wmem_max =3D 256000 # or less. or more. 5Mbit stream...fairly short rtts... hmm.. no brain cells. no sleep. ? This is another parameter that may apply, the last value should be changed. net.ipv4.tcp_wmem =3D 4096 65536 2097152 These of course change it globally. you commit the changes with sysctl -a -p /etc/sysctl.conf You can also tweak SO_SNDBUF in vlc via setsockopt http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html 64-256k seems about right but the math is eluding me this morning. You can turn off window scaling entirely, but that's not the right answer net.ipv4.tcp_default_win_scale =3D 0 the periodicity bothers me, it would be bad if that was synchronised, to look at that problem would require some synchronous captures from mutiple location. On Sat, Apr 7, 2012 at 11:10 AM, Steinar H. Gunderson wrote: > On Sat, Apr 07, 2012 at 08:10:50PM +0300, Jonathan Morton wrote: >> 12Mbps ADSL2+ in Finland (not at all far from Norway), via a standard >> modem-router rather than my usual Linux system. =A0The LAN segment is >> entirely wired full-duplex Ethernet. =A0The receiver is a Core i7 Window= s PC >> running the latest stable VLC, so it's not short of ability to play what= it >> receives. >> >> And it's dropping more frames than it's playing. > > Have you tried the one at cesur.tg12? It's pacing things out a bit more. > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net