[ENet-discuss] not enough throughput when packet loss is added
Lee Salzman
lsalzman at gmail.com
Fri Nov 24 19:31:31 UTC 2017
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
>
More information about the ENet-discuss
mailing list