<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Use tcpdump(1) on the flow and look for who is adding the latency. Usual rule of protocol debugging is to start at the lowest level and verify each level as you go up. Because then you have an audit trail of the events that happened which can inform you at a higher level.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 13, 2018 at 10:15 AM Oliver Korpilla <<a href="mailto:Oliver.Korpilla@gmx.de">Oliver.Korpilla@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello.<br>
<br>
We're using an elixir application as a sort of protocol tester. It communicated with the system-under-test over SCTP as a transport.<br>
<br>
We're observing delay and unsent messages and due to the nature of the SCTP protocol we're not sure which side causes the issue.<br>
<br>
The BEAM side has the NO_DELAY option set and pumps a burst of messages but then waits for responses (so it will not burst indefinitely, it burst once and then respond).<br>
<br>
The C++ application has the DELAYED_SACK option set - we tried with both sack_freq 1 (which supposedly disables the algorithm) and higher (the default in our system).<br>
<br>
(We also increased the receive window on both sides to ensure that senders would not block.)<br>
<br>
But we're stumped. The C++ side is not responding at some point. When we did an actual target test once and we saw SCTP messages sent from system-under-test just stop when analyzing the tcpdump of the interfaces - C++ application has not emitted something on the wire and respectively nothing is received.<br>
<br>
<br>
Our latest area of inquiry is to find out if maybe the elixir part is simply not getting scheduled - but can this impact for example SACK latency? Who acknowledges a message - the SCTP stack by itself or the application? And will the protocol block the sender until SACK?<br>
<br>
I'm sorry for asking such vague questions but SCTP know-how is spread thin in our outfit and we're not the experts...<br>
<br>
Thank you,<br>
Oliver<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">J.</div>