[icecast-dev] Second patch again CVS version

[mlyle at phoenix.lyle.org]

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.  

Since we send ~4k chunks, this equates to either:

NODELAY:
  1500 byte packet (1460 bytes data)
  1500 byte packet (1460 bytes data)
  1196 byte packet (1176 bytes data)

  == 2.9% overhead

NAGLE:
  1500 byte packet (1460 bytes data)
  1500 byte packet (1460 bytes data)
  1500 byte packet (1176 bytes data, plus 284 from next chunk).

  == 2.7% overhead

That .2% is significant when we're talking about low bandwidth links.
It also gets considerably worse when we take into account modem buffering,
smaller MTUs, and other network circumstances.

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.

Mike


-- 
M. Lyle

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.