On Feb 15, 2012 at 12:05, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: It's called when the kernel says it can write again on the respective socket. It might be that your consumer cannot read fast enough and so the buffers fill on ser/kamailio side. You might do something much more resource intensive on the receive side and it might not be able to keep up with the traffic (one connection is handled by one process, so if that process is too slow for some reason it might not read fast enough => on the transmit side the send buffers will fill-up). You could try changing the poll method and see if that makes any difference, e.g.: tcp_poll_method = sigio_rt in the .cfg file. The default is epoll-lt, so try "epoll-et", "sigio_rt2 and maybe "poll" (slow for lots of connections). Andrei

I now understand what is going wrong.... To make the xcap server work with the size of documents generated by the SIP client, I had to significantly increase the size of tcp_rd_buf_size. Increasing this value is what causes the problem described. Returning tcp_rd_buf_size to it's default size resolves the problem, but causes the upload of documents to the xcap server to fail. One way of solving this would be to allow the buffer size to be settable on a per connection basis, or perhaps separately for local connections. Does anyone have any thoughts, or other suggestions? Thanks Paul -----Original Message----- From: Andrei Pelinescu-Onciul Sent: Thursday, February 16, 2012 1:53 PM To: Daniel-Constantin Mierla Cc: Development mailing list of the sip-router project ; Paul Pankhurst Subject: Re: [sr-dev] Problem with TCP and EPOLL On Feb 15, 2012 at 12:05, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: It's called when the kernel says it can write again on the respective socket. It might be that your consumer cannot read fast enough and so the buffers fill on ser/kamailio side. You might do something much more resource intensive on the receive side and it might not be able to keep up with the traffic (one connection is handled by one process, so if that process is too slow for some reason it might not read fast enough => on the transmit side the send buffers will fill-up). You could try changing the poll method and see if that makes any difference, e.g.: tcp_poll_method = sigio_rt in the .cfg file. The default is epoll-lt, so try "epoll-et", "sigio_rt2 and maybe "poll" (slow for lots of connections). Andrei

On Feb 17, 2012 at 10:35, Paul Pankhurst <paul(a)crocodile-rcs.com> wrote: It's very strange that increasing the _receive_ buffer size would cause problems. Have you tried increasing also tcp_conn_wq_max (e.g 128k) and possibly tcp_wq_max? What's the output of sercmd core.tcp_info when you start to see problems (best just before that)? Andrei