> As a streaming server, it's fairly crucial for icecast to
> send out data with as low a delay as possible (many clients
> don't care, but some do). That's why we use TCP_NODELAY - we
> actually WANT to send out data as soon as we can.
Nagle is inherently unsuited for streams. NODELAY was (imho) ment for
connections for which Nagle isn't sufficient and CORK is not an option, i.e.
telnet.
Sending the data as soon as you can might not be the way to go, since this
has the potential to raise overhead significantly. I can explain this best
by grossly exxagerating, suppose i have an application that sends out 1 byte
at a time. Using NODELAY this would result in a dramatic increase of
overhead, since you would then basically use a 20 byte TCP header to send 1
byte, ie an overhead of 95%. If you reach a point where you think data
should be sent immediatly, you can also 'uncork' a connection, resulting
in
the data being sent immediatly.
Besides that, the biggest delay is the time the TCP packet spends to get to
it's intended destination (often > 10ms). NODELAY can lead to TCP packets
not being filled to their max, introducing extra delay because more packets
are being used.
Using CORK you make sure every TCP packet sent has been filled to it's
maximum payload. This minimizes the amount of packets used as well as
overhead.
> There are limits to how much overhead is reasonable to
> accept, which is why we do some aggregation in userspace;
> this aggregation should probably be tuned better, but it's
> important that icecast control it, not the kernel.
Why? What's the advantage? To me it looks more like creating an userspace
TCP/IP stack, and that doesnt seem usefull?
> You want TCP_CORK, it seems, because of bugs in your target
> devices
That is my main motivation indeed, however, imho there are more valid
reasons to want TCP_CORK, as i tried to explain above.
>- well, whilst we're willing to make some concessions
> to broken clients, an inability to speak TCP correctly is
> well outside what I consider sensible,
In your justification for nodelay, you state "(many clients don't care,
but
some do)", isn't that the same thing?
> that it will degrade icecast's performance for working
> clients (you remain welcome, of course, to hack up your local
> copy).
In most cases it would, in my opinion, enhance icecasts' performance, since
the optimum TCP packet size is being used. CORK would normally result in a
more stable data throughput (because each packet is filled to max) using
less bandwidth (due to minimizing overhead).
> It's also very unportable.
It is, that's why my first proposal was to incorporate it as a ./configure
option. That way you can leave the default the way it is now, but give end
users the option of using it.
However i will cleanup the patch for distribution and then sent it to those
who requested it. I hope you'll reconsider applying it to the main tree.
Regards,
Henri Zikken
