[icecast-dev] Second patch again CVS version

[Ricardo Galli]

On 24/02/02 10:06, mlyle at phoenix.lyle.org shaped the electrons to say:
> On Sun, Feb 24, 2002 at 09:04:03AM +0100, Ricardo Galli wrote:
> > Sorry, didn't explain well.
> >
> > Nagle's  algorithm (rfc896) buffers user data until there is no pending
> > acks or it can send a full segment (rfc1122).
> >
> > icecast doesn't need it at all, because it already sends large buffers
> > and the time to send the next buffers is relatively very long.
>
> IMO we should be using the nagle algorithm.   It greatly reduces protocol
> overhead and there will always be less than 1500 bytes unsent.  This is
> small compared to the average client buffer size of 32k.
...
> The advantage to not using the nagle algorithm is that client buffers will
> be on average 750 bytes fuller.  This is only 1/4 second of audio even at
> 24kbps.

I've tested both cases, with a VBR of 26 kbps average. There is no difference 
on how the packets are assembled. Most probably due to timeouts.

Find enclosed a tcpdump output of 30 seconds of streaming behind a ISDN line. 

Regards,


-- 
  ricardo
"I just stopped using Windows and now you tell me to use Mirrors?" 
    - said Aunt Tillie, just before downloading 2.5.3 kernel.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: delay.txt.gz
Type: application/x-gzip
Size: 3275 bytes
Desc: delay.txt.gz
Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20020224/b59c71f9/delay.txt.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_delay.txt.gz
Type: application/x-gzip
Size: 3224 bytes
Desc: no_delay.txt.gz
Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20020224/b59c71f9/no_delay.txt.bin