[Spread-users] sporadic latencies with SP_receive

[Johannes Wienke]

Dear all,

we encountered some latency issues in our applications using spread.
Today we tried to isolate the problem and came up with a test program
that demonstrates the behavior.

Generally, the observation is that in a threaded setup, using local
communication, and a small sleep between calls to SP_receive, these
receive calls sometimes take up to 100 ms, e.g. generating this log:

receive took 55 us
receive took 68 us
receive took 97071 us
receive took 54 us
receive took 67 us
receive took 97060 us
receive took 54 us
receive took 68 us
receive took 97086 us
receive took 56 us
receive took 69 us
receive took 97091 us
receive took 56 us
receive took 67 us
receive took 97071 us

The attached program exactly produces this output. Please note that this
only happens if the sleep call is present in line 108.

We have also verified that this is not related to the architecture we
are running on (Linux 32 and 64 bit), nevertheless we got a stack
corruption on 32 bit in the sender thread with a privateGroup array only
MAX_PRIVATE_NAME characters long. Thus the increased size. Is this also
a known problem?

We would be happy to get some insights or fixes in how to prevent this
issue. In a real application the sleep is usually not required to
trigger the problem as the receiving thread is still doing other things
in its loop.

Regards,
Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spreadtest.cpp
Type: text/x-c++src
Size: 3042 bytes
Desc: not available
Url : http://lists.spread.org/pipermail/spread-users/attachments/20110725/26f4d82f/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.spread.org/pipermail/spread-users/attachments/20110725/26f4d82f/attachment-0001.bin