[ENet-discuss] not enough throughput when packet loss is added
cbarrett.colo at gmail.com
Fri Nov 24 21:17:31 UTC 2017
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.
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>
> > I have a streaming uncompressed audio application. It is a round trip
> > from node A to node B and then back to node A. A is setup as a client.
> > 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,
> > 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
> > delay in each direction - fails consistently with not enough throughput.
> > Thus, the buffers at either node deplete relatively quickly (~2 seconds)
> > the stream is broken, falls behind.
> > I have set both enet hosts up for infinite bandwidth. I believe the
> > bandwidth capacity is very large, > 100 Mbit. I setup the network
> > conditioner (that is simulating the packet loss and network delay) to
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ENet-discuss