Hi,
I use the same test as I sent to the alias ealier.
SIPp UAC ---SER--SIPp UAS
199.199.2.31 199.199.2.50 199.199.2.30
Problem: SIPp UAC get broken pipe error with high load
(800CPS).
Traces show the cause is as follows:
With high load, one cpu @ SER is
Hi,
I am using SIPp and SER for some performance study and
get several errors when using TCP protocol. From the
packet trace, I notice when TCP publicize zero window
at SIPp or SER side, SIP message will get truncated or
several partial or whole SIP message get combined in
one TCP packet, which
What release of SIPp are you using? The latest (1.1-rc8) has lots of TCP
fixes, which should hopefully solve your problems.
Charles
[EMAIL PROTECTED] wrote on 01/09/2007 01:26:53 PM:
Hi,
I am using SIPp and SER for some performance study and
get several errors when using TCP protocol.
Hi Charles,
I see you have made a lot of changes to TCP handling
in SIPp. Could you explain how SIPp decides if a SIP
message is complete or partial? Since I suspect the
problem I am seeing could be caused by SIP message
compatibility issue between SER and SIPp.
thanks,
Joy
--- Charles P
SIPp will read a message until it finds a \r\n\r\n, at which point it
knows that it received the headers. Next it finds the Content-Length
header in the message, and if it exists reads the number of bytes
specified in the content length header. A message is not complete until
the full number
Hi Klaus,
well, there are several issues with respect to TCP code, including bad
and slow TCP reading (1 octet at a time) - but this is another story...
I have been reading through the issue you reported and was discussed
Edward Russell wrote:
Problem solved - I guess.
I modified sipp.cpp and removed all occurences of O_NONBLOCK and
MSG_DONTWAIT (the flag passed to send, not the #define).
I can now successfully do 1000 1 second calls at the rate of 200 per
second.
Good enough for me, but I'm sure this
Looking at the source, it appears to me that when sipp gets back EAGAIN
or EWOULDBLOCK on a TCP send, it writes to trace and counts it as
congestion, but does nothing regarding trying again. (sipp.cpp, lines
1765 -- 1829).
Darilion
Cc: Edward Russell; sipp-users@lists.sourceforge.net
Subject: Re: [Sipp-users] TCP problems under high load
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
