[Spread-users] sporadic latencies with SP_receive

[John Schultz]

Johannes,

I am beginning to work on a new release of Spread that I hope to be able to put out by the end of this month.

I will take a look at your program and see if I can replicate your results.  If I can, then I'll try to dig down further into the issue.  It strikes me as potentially an issue with thread-switching / mutex locking and the "OS resolution" on such switches.

The MAX_PRIVATE_NAME thing is a bit weird because that is the expected size of the arrays whereas a C string has to be nul terminated, meaning a spread group name can really only be MAX_PRIVATE_NAME - 1 characters long (+ a nul terminator).  I doubt we can change this to align these two slightly different, off by one, meanings without breaking backwards some programs already out there, but I will look into it too.
 
Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Phn: 301 830 8100
Cell: 443 838 2200

On Aug 4, 2011, at 6:44 AM, Johannes Wienke wrote:

Hey again,

sorry for bumping, but are there any ideas how and why this happens? It
really decreases our performance right now.

Regards,
Johannes

On 07/25/2011 01:47 PM, Johannes Wienke wrote:
> 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
> 
> 
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users


_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3805 bytes
Desc: not available
Url : http://lists.spread.org/pipermail/spread-users/attachments/20110804/fdf6f627/attachment.bin