On Wed, 2008-04-02 at 23:05, Charles P Wright wrote:
> My best guess is that if you look at the default messages in the source,
> that ACK will match up relatively nicely to one of them in there rather
> than it coming from some sort of corruption.
Yes, it turns out to be the case, but why we get to that code is still a
mystery -- it's coming from abortCall() and likely process_unexpected()
but I can't quite catch that. Still, this happens quite rarely, and
there's a more general issue with the ACKs that I'll show below
(originally, I thought it was all the same, but it turns out not to be).
> I would also be interested if you can provide any more information about
> regressions you've seen.
I'm beginning to think that what I'm seeing is a different manifestation
of the same symptom I see in the stable build. In general, I see more
errors and a longer reported avg call length (maybe 20-30% more) at the
end of a run -- but the call length is, I suspect, at least partly
because of the extra error processing time. It could also be a compile
issue -- I can't compile the latest code with the SunStudio compiler I
used for the stable code, though I don't really think that there is a
signficant difference between that at gcc these days.
About those errors -- I'm increasingly convinced that something is wrong
in the combination of optional messages received out of order and
congestion. If I run 100 calls in the latest code (well, the latest I
checked out, which is SVN version 424), the uac reports this:
Call limit reached (-m 100), 0.494 s period 1 ms scheduler resolution
0 calls (limit 1536) Peak was 62 calls, after 0 s
0 Running, 100 Paused, 0 Woken up
17 dead call msg (discarded) 0 out-of-call msg (discarded)
2 open sockets
Messages Retrans Timeout Unexpected-Msg
INVITE ----------> 100 0 0
100 <---------- 100 0 0 0
180 <---------- 85 0 0 0
200 <---------- E-RTD1 122 0 0 0
ACK ----------> 122 0
Pause [ 0ms] 122 0
BYE ----------> 122 0 0
200 <---------- 78 0 0 22
There's just some bad call-matching going on there; there shouldn't 22
extra 200OK received to from the INVITE; clearly they belong to the BYE
(and then the 22 extra BYEs cause 22 481s to be received).
For comparison, here's what I see in the stable build:
Call limit reached (-m 1000), 0.660 s period 9 ms scheduler
resolution
172 calls (limit 1536) Peak was 858 calls, after 1 s
0 Running, 172 Paused, 0 Woken up
0 out-of-call msg (discarded)
2 open sockets 0/0/12 TCP errors
(send/recv/cong)
Messages Retrans Timeout
Unexpected-Msg
INVITE ----------> 1000 0 0
100 <---------- 1000 0 0 0
180 <---------- 933 0 0 0
200 <---------- E-RTD1 1000 0 0 0
ACK ----------> 829 0
Pause [ 0ms] 829 0
BYE ----------> 829 0 0
200 <---------- 828 0 0 0
At this point, the uac never sends anything else; for some reason it has
dropped 171 200 responses and not sent out an ACK. [But I don't see 171
of the abort-call generated ACKs either -- possibly there are two
different things going on.]
If a GLOBAL optional message is received out of order, perhaps it should
just be ignored (that is, after incrementing the recv counter,
call::process_incoming() could return without processing the rest)? That
certainly fixes the issue for me (on both the stable and trunk builds).
Or perhaps there could be an optional="ingore" tag for that case?
-Scott
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
