<div dir="ltr">Hi all,<div><br></div><div><div>I am using ENet in a new application where I have a Windows PC (Windows 7) communicating with an ARM-based computer running Linux. They are connected via Ethernet on the same LAN. I use a few small reliable packets that are sent back and forth at about 4Hz, which works really well. The ENet version I've been using is 1.3.11.<br>
</div><div><div><br></div><div>The ARM device is set up as host, the Windows PC connects as a client. Both are set up with "unlimited bandwidth" in both directions. </div></div><div><br></div><div>The Windows PC also has to send larger unreliable packets to the ARM device. Each packet is 115200 bytes, and is sent at 10Hz. As I don't really need any throttling mechanisms, I've disabled this by setting the deceleration parameter on the throttle configuration to zero. The Ethernet connection can handle much more data than this and is not used by anything else.</div>
<div><br></div><div><div>Some times this works fine, but more often it seems like the unreliable packets are buffered somewhere on the way. I can have up to about 30 seconds latency (!) until they arrive at the "receiving end" (enet_host_service loop). However, no packets are lost. At the same time, there is no latency for the other smaller reliable packets. </div>
</div><div><br></div><div>I call enet_host_service fairly often, the interval on the Windows PC is around 5 ms, the ARM device does this every 30 ms. I've checked the incoming udp buffer in Linux. It seems to be read often enough, so it seems like the packets are buffered on the Windows PC before even being sent. </div>
<div><br></div><div>Is there some hard-coded max bandwidth setting in ENet that I have exceeded? Does it have an "outgoing buffer" that can grow this much? Have any of you seen any similar behavior? </div><div><br>
</div><div>Best regards,<br></div><div>Ola Røer Thorsen</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>