On Jun 14, 2010 at 12:37, marius zbihlei
<marius.zbihlei(a)1and1.ro> wrote:
Andrei Pelinescu-Onciul wrote:
Anyway from the coding point of view I'm
almost ready, the testing will
be more difficult.
Andrei
Hello Andrei,
I might help with testing and providing some performance numbers.
Thanks a lot!
Unfortunately I only have access to some quad
core Xeon servers, not
8 cores.
If the weird UDP behavior appears also on 4 cores(less lock
contention), I can run a test plan.
My idea is to have several UDP workers (I plan to use 8- this will
allow the kernel to distribute them evenly on all 4 CPUs - as the
machine is idle). I plan to test using other 2-3 machines for
sending SIP messages (using sipp or sipsak). Ser will just send some
replies with some error code. I will measure the throughput over a
1 minute interval on the ser machine, with both current UDP sender
and the new UDP over raw sock sender.
If this is ok then in the afternoon I will bring some results. Any
suggestion regarding the test plan is welcomed.
Well, while there is little more to be done, the code is not yet testing
ready (a few small things like on-send fragmentation and integration in
ser are still missing). I'll have it ready sometime this week, but I'm
not sure I'll have time do it today or tomorrow.
Hello,
I want to test using some small sip replies(so I am not sure if
fragmentation takes part). Of course the fragmentation code should also
be tested for performance. Ser integration is another issue. Do you plan
to use a global parameter to switch between normal sendto() function and
raw sockets ?
Marius