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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > http://lists.cubik.org/mailman/listinfo/enet-discuss > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
