
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 6 Apr 2012, at 12:39, Per Hedeland wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Exactly - which raises the question, what *is* the point of having a<br>send queue? I.e. the user-level queue that inet_drv maintains, and which<br>is causing these problems. I don't know, but since Tony has joined the<br>discussion, maybe he can answer.:-)<br></span></blockquote></div><br><div>Far enough removed from the question - not having looked into the code - I may end up with egg on my face for butting in, but…</div><div><br></div><div>I recall diskussions about the send queue being there to make sending non-blocking from the erlang side, even if the socket returns EAGAIN.</div><div><br></div><div>This was taken a step further when trying to optimize e.g. the AXD 301 & co, such that one could opt to always enter the send queue directly. This achieved a 'bulking' effect which significantly (10-20%, if I recall) improved throughput.</div><div><br></div><div>(This would be the {delay_send, boolean()} option. If this isn't relevant to the discussion at hand, my apologies).</div><div><br></div><div>BR,</div><div>Ulf W</div></body></html>