Rick Jones wrote: > 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.
I saw some empty packets which ethereal decoded as "TCP keep-alive". They where sent every 0,5s to 3s (I can't remember exactly). > 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. The thing is, once the receiver buffer at the SIP proxy is full, of course the sending buffer at the SIPp side also gets full as SIPp still writes SIP packets into the socket. IMO SIPp should stop sending (and stop reporting) SIP messages into the socket. Currently, if the socket does not accept any data (sending buffer is full), SIPp buffers the messages and reports them as sent, which is IMO wrong. > 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. Yes, that's exactly what happens. Using multiple SIPp instances does not help. regards klaus > > 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
