From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lanfw001a.cxnet.dk (lanfw001a.cxnet.dk [87.72.215.196]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6AAAB200B33 for ; Sat, 7 Apr 2012 14:14:01 -0700 (PDT) Received: from comxexch02.comx.local (unknown [172.31.1.117]) by lanfw001a.cxnet.dk (Postfix) with ESMTP id 8CB00163517; Sat, 7 Apr 2012 23:13:59 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1503.5999CB9C" Date: Sat, 7 Apr 2012 23:13:59 +0200 Message-ID: <9B4DB5BB110D1742A9FBC310C8011FD303E58D@comxexch02.comx.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bloat] Best practices for paced TCP on Linux? Thread-Index: Ac0U8OHKMJ7O0OqxRMuJqbttxpn+8wADzkis References: <20120406213725.GA12641@uio.no><20120406222138.GB12641@uio.no><1333811327.30705.4.camel@edumazet-laptop><20120407153548.GC21452@uio.no><20120407181034.GD21452@uio.no><20120407185456.GE21452@uio.no> <20120407190134.GF21452@uio.no> From: "Jesper Dangaard Brouer" To: "Steinar H. Gunderson" , "Dave Taht" 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 21:14:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1503.5999CB9C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steinar, The stream from http://pannekake.samfundet.no:3013 is fairly stable, compared to e.g. http://cesur.tg12.gathering.org:9094/, but is clear that sometimes excessive buffering does occur. Try to looking at the Recv-Q size, e.g. using the command "netstat = -tan". Some time you will see it grows, see the output below, where it reached 400Kbytes. This is data avail to the application (in the kernel), but not yet processed/read by the VLC application. [hawk@t520 norsk-streaming]$ netstat -tan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State [...cut...] tcp 400312 0 192.168.42.180:59826 129.241.93.35:3013 = ESTABLISHED While writing this email, I saw it jump upto 949690 bytes, and the signal quality went down. --Jesper Brouer -----Original Message----- From: bloat-bounces@lists.bufferbloat.net on behalf of Steinar H. = Gunderson Sent: Sat 4/7/2012 21:01 To: Dave Taht Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Best practices for paced TCP on Linux? =20 On Sat, Apr 07, 2012 at 08:54:56PM +0200, Steinar H. Gunderson wrote: > I did these on one of the irrors (well, I did 500000 instead of = 256000). > You can try >=20 > http://pannekake.samfundet.no:3013/ (SD) > http://pannekake.samfundet.no:3015/ (HD) >=20 > I didn't restart VLC; I hope I don't have to. =3D) I got reports from people in Norway that this instantly stopped the = problems on the HD stream, so incredibly enough, it may have worked. I don't understand these mechanisms. Why would a smaller send window = help? Less burstiness? /* Steinar */ --=20 Homepage: http://www.sesse.net/ _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ------_=_NextPart_001_01CD1503.5999CB9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Bloat] Best practices for paced TCP on Linux?

Hi Steinar,

The stream from http://pannekake.samfundet.no= :3013 is fairly stable,
compared to e.g. http://cesur.tg12.gatherin= g.org:9094/, but is clear
that sometimes excessive buffering does occur.

Try to looking at the Recv-Q size, e.g. using the command "netstat = -tan".
Some time you will see it grows, see the output below, where
it reached 400Kbytes.  This is data avail to the application (in = the
kernel), but not yet processed/read by the VLC application.

[hawk@t520 norsk-streaming]$ netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local = Address          Foreign = Address     State
[...cut...]
tcp   400312      0 = 192.168.42.180:59826   129.241.93.35:3013  = ESTABLISHED

While writing this email, I saw it jump upto 949690 bytes, and the
signal quality went down.

--Jesper Brouer



-----Original Message-----
From: bloat-bounces@lists.bufferbloat.net on behalf of Steinar H. = Gunderson
Sent: Sat 4/7/2012 21:01
To: Dave Taht
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Best practices for paced TCP on Linux?

On Sat, Apr 07, 2012 at 08:54:56PM +0200, Steinar H. Gunderson = wrote:
> I did these on one of the irrors (well, I did 500000 instead of = 256000).
> You can try
>
>   http://pannekake.samfundet.n= o:3013/ (SD)
>   http://pannekake.samfundet.n= o:3015/ (HD)
>
> I didn't restart VLC; I hope I don't have to. =3D)

I got reports from people in Norway that this instantly stopped the = problems
on the HD stream, so incredibly enough, it may have worked.

I don't understand these mechanisms. Why would a smaller send window = help?
Less burstiness?

/* Steinar */
--
Homepage: http://www.sesse.net/
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buffe= rbloat.net/listinfo/bloat

------_=_NextPart_001_01CD1503.5999CB9C--