SIPP: open file limit > FD_SETSIZE

actually I try to start SIPP 3.3 on opensuse 11 with a bash console with java. When I start SIPP with

proc = Runtime.getRuntime().exec("/bin/bash", null, wd);


printWriter.println("./sipp -i "+Config.IP+" -sf uac.xml "+Config.IP+":5060");

the error stream gives the following output

Warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE = 1024 Resolving remote host ''... Done.

What does the warning means? And is it possible that the bash terminal freezes because of this warning? How can i remove this warning?


This warning is supposedly related to multi-socket transport options in SIPp eg. '-t un' or '-t tn', (though I have observed it generate these warnings even when not specifying one of these).

SIPp includes an option that controls this warning message:

   -skip_rlimit     : Do not perform rlimit tuning of file descriptor limits.  Default: false.

Though it has the desired effect for me of suppressing the warning output, on its own, it seems like a slightly dangerous option. Although I'm not certain of what will happen if you include this option and SIPp attempts to open more sockets than are available according to FD_SETSIZE, you may avoid possible problems on that front by also including the max_socket argument:

   -max_socket      : Set the max number of sockets to open simultaneously. This option is
                      significant if you use one socket per call. Once this limit is reached,
                      traffic is distributed over the sockets already opened. Default value is

I'm the maintainer of SIPp and I've been looking into the FD_SETSIZE issues recently.

As is mentioned at Increasing limit of FD_SETSIZE and select, FD_SETSIZE is the maximum file descriptor that can be passed to the select() call, as it uses a bitfield internally to keep track of file descriptors. SIPp had code in it to check its own maximum open file limit (i.e. the one shown by ulimit -n), and if it was larger than FD_SETSIZE, to reduce it to FD_SETSIZE in order to avoid issues with select().

However, this has actually been unnecessary for a while - SIPp has used poll() rather than select() (which doesn't have the FD_SETSIZE limit, and has been POSIX-standardised and portable since 2001) since before I became maintainer in 2012. SIPp now also uses epoll where available for even better performance, as of the v3.4 release.

I've now removed this FD_SETSIZE check in the development code at, and replaced it with a more sensible check - making sure that the maximum number of open sockets (plus the maximum number of open calls, each of which may open its own media socket) is below the maximum number of file descriptors.

Need Your Help

How to use RtlDecompressBuffer without knowing the size of the uncompressed data?

c winapi

I would like to use the WINAPI RtlDecompressBuffer in User Mode to decompress a buffer previously compressed using RtlCompressBuffer. I have the code for compression but it seems that in order to

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.