Re: [Bloat] Best practices for paced TCP on Linux?

["Jesper Dangaard Brouer" <jdb@comx.dk>]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

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?
 
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.no:3013/ (SD)
>   http://pannekake.samfundet.no:3015/ (HD)
> 
> I didn't restart VLC; I hope I don't have to. =)

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.bufferbloat.net/listinfo/bloat


[-- Attachment #2: Type: text/html, Size: 2921 bytes --]