<div dir="ltr">I built a TCP (boost/asio) solution first and got OK performance (lowest latency with no dropped packets).  I was trying UDP/enet just to see if I could get better performance.  So, now I have my answer.<div><br></div><div>Thanks,</div><div>Chris</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 24, 2017 at 12:31 PM, Lee Salzman <span dir="ltr"><<a href="mailto:lsalzman@gmail.com" target="_blank">lsalzman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you're shuttling that much primarily reliable data back and forth,<br>
you should really just be using TCP. You will get the best performance<br>
that way.<br>
<div><div class="h5"><br>
On Fri, Nov 24, 2017 at 1:56 PM, Chris Barrett <<a href="mailto:cbarrett.colo@gmail.com">cbarrett.colo@gmail.com</a>> wrote:<br>
> I have a streaming uncompressed audio application.  It is a round trip path<br>
> from node A to node B and then back to node A.  A is setup as a client.  B<br>
> is setup as a host.  The links can have up to three 48k/24bit PCM audio<br>
> channels - thus 1.1 Mbit each, plus one setup/control channel with<br>
> negligible bandwidth requirements.  This application cannot have errors, so<br>
> enet packets are all setup as reliable.<br>
><br>
> I have tried these cases:<br>
><br>
> (1) One audio channel, no packet drops, no network delay - works great.<br>
> (2) One audio channel, 0.85% packet loss in each direction, 120ms network<br>
> delay in each direction - works great with ~900ms buffer at both A and B<br>
> (3) Two audio channels, no packet drops, no network delay - works great.<br>
> (4) Two audio channels, 0.85% packet loss in each direction, 120ms network<br>
> delay in each direction - fails consistently with not enough throughput.<br>
> Thus, the buffers at either node deplete relatively quickly (~2 seconds) and<br>
> the stream is broken, falls behind.<br>
><br>
> I have set both enet hosts up for infinite bandwidth.  I believe the network<br>
> bandwidth capacity is very large, > 100 Mbit.  I setup the network<br>
> conditioner (that is simulating the packet loss and network delay) to have<br>
> 60 Mbit bandwidth...so I don't think it is the problem.<br>
><br>
> At both nodes I have enet_host_service setup in it's own task, so I believe<br>
> enet is always able to perform any necessary work.<br>
><br>
> Any ideas?  I see there is some sort of throttling algorithm in enet, but it<br>
> appears to be used to limit unreliable communication (?).  Any ideas?<br>
><br>
> Thanks,<br>
> Chris<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> ENet-discuss mailing list<br>
> <a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
> <a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" rel="noreferrer" target="_blank">http://lists.cubik.org/<wbr>mailman/listinfo/enet-discuss</a><br>
><br>
______________________________<wbr>_________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" rel="noreferrer" target="_blank">http://lists.cubik.org/<wbr>mailman/listinfo/enet-discuss</a><br>
</blockquote></div><br></div>