Klaus Darilion wrote: > Edward Russell wrote: > >>I am seeing what I think is the same thing. I have two sipp >>communicating with each other doing 1000 1 second calls. As I crank the >>call rate to 20 per second, the answer side sees about 25 unexpected >>messages. If I set the call rate to 200 per second, the answer side sees >>about 220 unexpected messages. >> >>I have not diagnosed this scenario further yet, but when I stick our RTP >>proxy in the middle (which is what I am really testing) I do see some >>log messages (from our proxy) that are missing the call id. >> >>Any more thoughts on this? My solution, I guess, will be to launch 20 >>sipps for the calling side, each sending 10 calls per second. > > > Not sure if this would help. In my case, the problems appeared when the > TCP window size of the SIP proxy was set to 0 (=the SIP proxy is > overloaded and the receiving buffer is full). > > That means, there is no difference if there is one SIPP with 5000 > calls/s or 10 SIPPs with each 500 calls/s - at total there are 5000 > calls, the SIP proxy is overloaded, the TCP window size will be set to 0 > (on one ore more TCP connections) and SIPP behaves broken.
I'm completely out of my depth when it comes to SIP/SIPp, but have a little experience with TCP - if the TCP window goes to zero it does indeed mean that the receiving application has not been keeping-up with the traffic flow on the TCP connection. The sending TCP is stuck waiting for the window to open. The receiving TCP may indeed open the window when the applicatoin recv's enough data out of it, but sending TCP's also have something called (IIRC) a window probe triggered by a persist timer. That timer is (intiially) on the order of the normal TCP retransmission timer. That is on the order of several hundred milliseconds. So, if there is code expecting timely response on the TCP connection, when the TCP connection's window fills it could easily not get that result in a timely fashion and it could be all down the tubes from there. Having multiple TCP connections would mean multiple windows which means it would take longer for the sum of the windows to fill - however if those connections are all to the same process/thread that process/thread could become just as loaded as before and the windows could still fill. rick jones http://www.netperf.org/ Strictly speaking, application send's on the TCP connection won't start to block, or return EAGAIN/EWOULDBLOCK (when non-blocking) until the SO_SNDBUF fills, which could happen after the remote receiver's TCP window has filled. That also could happen before the remote receiver's TCP window fills - it all depends on the value of the remote receiver's window and SO_SNDBUF on the sender. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
