Can I bump the TCP window size, or do you simply mean at some point the receiving buffer will be full and the problem will start?
Now I understand why you ask about running in blocking mode. Can't I just recompile without the O_NONBLOCK flag? In fact, in send_packets.c there is an #ifdef MSG_DONTWAIT. Unfortunately I don't see this defined anywhere so I think it is already compiled for "WAIT" mode? Maybe not, because send_packets.c only gets compiled with "make pcapplay" so does that mean the send in send_packets.c is ONLY used for RTP (which is not where our problem is). Ed -----Original Message----- From: Klaus Darilion [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 11:52 AM To: Edward Russell Cc: [email protected] Subject: Re: [Sipp-users] TCP problems under high load 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. regards klaus > Ed > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Klaus > Darilion > Sent: Wednesday, July 26, 2006 5:51 PM > To: [email protected] > Subject: [Sipp-users] TCP problems under high load > > Hi! > > I made some tests with ser and sipp with high TCP load. > > Scenario: sipp sends INVITE, ser answers with 404. > > After some seconds (~3000 INVITEs/s) ser reports bad SIP messages. I > used ngrep to sniff the TCP flow, and found out, that sometimes some > INVITE requests are missing (no continuous increasing call id). As the > sequence number in the TCP packages sent by sipp are continuous, I > suspect sipp to "forget" to put some data into the sending socket. > > Maybe this is caused due to nonblocking socket operation and buggy > handling of EAGAIN? > > I attach the discussion from the ser mailing list with my detailed > analysis. Thread: > http://lists.iptel.org/pipermail/serusers/2006-July/029809.html > > maybe someone can review the code for sending messages. > > btw: is it possible to use sipp in blocking mode? > > thanks > klaus > > > > > tcp_read_req already receives a broken message: > > 3(30034) calling receive_msg(0x2a9635cb40, 520, ) > 3(30034) tcp_read_req: preparing for new request, kept 3056 bytes > 3(30034) read= 0 bytes, parsed=536, state=4, error=1 > 3(30034) tcp_read_req: last char=0x0A, parsed msg= INVITE > sip:serviINVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 > Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20964-0 > From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20964 > To: sut <sip:[EMAIL PROTECTED]:5060> > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: sip:[EMAIL PROTECTED]:5062 > Max-Forwards: 70 > Subject: Performance Test > Content-Type: application/sdp > Content-Length: 135 > > v=0 > o=user1 53655765 2353687637 IN IP4 83.136.32.91 > s=- > c=IN IP4 83.136.32.91 > t=0 0 > m=audio 6002 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > 3(30034) tcp_read_req: end of header part > 3(30034) - received from: port 32978 > 3(30034) tcp_read_req: headers: > INVITE sip:serviINVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 > Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20964-0 > From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20964 > To: sut <sip:[EMAIL PROTECTED]:5060> > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: sip:[EMAIL PROTECTED]:5062 > Max-Forwards: 70 > Subject: Performance Test > Content-Type: application/sdp > Content-Length: 135 > > . > 3(30034) tcp_read_req: content-length= 135 > 3(30034) tcp_read_req: body: > v=0 > o=user1 53655765 2353687637 IN IP4 83.136.32.91 > s=- > c=IN IP4 83.136.32.91 > t=0 0 > m=audio 6002 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > 3(30034) calling receive_msg(0x2a9635cb40, 536, ) > 3(30034) ERROR:parse_first_line: bad request first line > 3(30034) ERROR: at line 0 char 52: > 3(30034) ERROR: parsed so far: INVITE sip:serviINVITE > sip:[EMAIL PROTECTED]:5060 > 3(30034) ERROR:parse_first_line: bad message > 3(30034) ERROR: parse_msg: message=<INVITE sip:serviINVITE > sip:[EMAIL PROTECTED]:5060 SIP/2.0 > > > > I traced the message with tcpdump: > the message before the suspect one is (note the last line!!!): > INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 > Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20924-0 > From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20924 > To: sut <sip:[EMAIL PROTECTED]:5060> > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: sip:[EMAIL PROTECTED]:5062 > Max-Forwards: 70 > Subject: Performance Test > Content-Type: application/sdp > Content-Length: 135 > > v=0 > o=user1 53655765 2353687637 IN IP4 83.136.32.91 > s=- > c=IN IP4 83.136.32.91 > t=0 0 > m=audio 6002 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > INVITE sip:servi > > > > the next message is: > > INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 > Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20964-0 > From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20964 > To: sut <sip:[EMAIL PROTECTED]:5060> > Call-ID: [EMAIL PROTECTED] > CSeq: 1 INVITE > Contact: sip:[EMAIL PROTECTED]:5062 > Max-Forwards: 70 > Subject: Performance Test > Content-Type: application/sdp > Content-Length: 135 > > v=0 > o=user1 53655765 2353687637 IN IP4 83.136.32.91 > s=- > c=IN IP4 83.136.32.91 > t=0 0 > m=audio 6002 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > > Thus (sipp uses increasing call id), the requests 20925 - 20963 are > missing in the network dump. Lost during capture? No, because the > sequence numbers of the packets are fine - no gap. > > Thus, I suspect sipp to "loose" some data. Hmmm. Any alternatives to > sipp? > > > > ---------------------------------------------------------------------- > -- > - > 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=DEV > DE > V > _______________________________________________ > Sipp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sipp-users ------------------------------------------------------------------------- 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
