[ENet-discuss] not enough throughput when packet loss is added

[Chris Barrett]

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.

Thanks,
Chris

On Fri, Nov 24, 2017 at 12:31 PM, Lee Salzman <lsalzman at gmail.com> wrote:

> If you're shuttling that much primarily reliable data back and forth,
> you should really just be using TCP. You will get the best performance
> that way.
>
> On Fri, Nov 24, 2017 at 1:56 PM, Chris Barrett <cbarrett.colo at gmail.com>
> wrote:
> > I have a streaming uncompressed audio application.  It is a round trip
> path
> > from node A to node B and then back to node A.  A is setup as a client.
> B
> > is setup as a host.  The links can have up to three 48k/24bit PCM audio
> > channels - thus 1.1 Mbit each, plus one setup/control channel with
> > negligible bandwidth requirements.  This application cannot have errors,
> so
> > enet packets are all setup as reliable.
> >
> > I have tried these cases:
> >
> > (1) One audio channel, no packet drops, no network delay - works great.
> > (2) One audio channel, 0.85% packet loss in each direction, 120ms network
> > delay in each direction - works great with ~900ms buffer at both A and B
> > (3) Two audio channels, no packet drops, no network delay - works great.
> > (4) Two audio channels, 0.85% packet loss in each direction, 120ms
> network
> > delay in each direction - fails consistently with not enough throughput.
> > Thus, the buffers at either node deplete relatively quickly (~2 seconds)
> and
> > the stream is broken, falls behind.
> >
> > I have set both enet hosts up for infinite bandwidth.  I believe the
> network
> > bandwidth capacity is very large, > 100 Mbit.  I setup the network
> > conditioner (that is simulating the packet loss and network delay) to
> have
> > 60 Mbit bandwidth...so I don't think it is the problem.
> >
> > At both nodes I have enet_host_service setup in it's own task, so I
> believe
> > enet is always able to perform any necessary work.
> >
> > Any ideas?  I see there is some sort of throttling algorithm in enet,
> but it
> > appears to be used to limit unreliable communication (?).  Any ideas?
> >
> > Thanks,
> > Chris
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20171124/d689bea1/attachment.html>