<div dir="ltr">Even if you were doing almost everything wrong I don't see how you could get a 30s latency on packets just by mishandling ENet settings. There is nothing that would be limiting it that drastically except the OS network stack/hardware itself. Make sure the computers are actually capable of sending 1MB/s back and forth, as that is the only thing I could think of.<div>
<br></div><div>Also if you're sure there's almost no packet loss, you can try ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT so that those large packets don't get forced reliable. Though to lose even a single 1400 byte fragment of the 115200 byte packet will mean the entire packet gets lost, so this is not a good idea, IMO... By default, there's not really such a thing as an unreliable 115200 byte packet unless you use that flag, though, since the default is that fragmented packets get set to reliable.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 5, 2014 at 11:49 AM, Ola Røer Thorsen <span dir="ltr"><<a href="mailto:ola@silentwings.no" target="_blank">ola@silentwings.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>