[Icecast] Use of TCP_CORK instead of TCP_NODELAY

[Karl Heyes]

Klaas Jan Wierenga wrote:
>>This is exactly why it was implemented, a few people complained about
>>the overhead with large numbers of listeners, not only because of the
>>TCP overhead but also the fact that it reduces the write syscall
>>overhead. Will TCP_CORK (linux) and TCP_NOPUSH (BSD) give noticable
>>benefits wrt icecast? It might prove helpful if available but more info
>>is needed.
> 
> 
> As Christopher Baus points out in his article
> http://www.baus.net/on-tcp_cork it is not so much the overhead of a few
> write calls that affects performance, but the overhead in sending more
> smaller packets. In my case sending small packets resulted in a lot of
> interrupts (one or two for each packet sent) for many listeners listening to
> low bitrate streams. This resulted in jerky playback because the machine
> simply couldn't keep up. With icecast 2.3.0 the interrupt rate at the same
> level of listeners has been reduced by more than 50%.

I understand what you are saying about the interrupt rate, that is why I 
added the batching up of the read data, which applies to all platforms. 
The article in question doesn't deal with the exact same situation as 
icecast, for instance we don't want icecast to do say 100 write syscalls 
where each one is something like 50 bytes, for each listener. TCP_CORK 
or not, it's still wasteful.

TCP_CORK/TCP_NOPUSH may be useful (where available), but doing some 
tests would be the way forward, especially as 2.3 has helped your 
situation already.

karl.