[ENet-discuss] Huge latency issue with larger unreliable packets

[Lee Salzman]

You can change the value of the ENET_HOST_DEFAULT_MTU define in the
headers. Currently it is 1400. Just make sure you change that on both ends.

As far as packet loss goes, there is a variable in all peers:

    enet_uint32   packetLoss;          /**< mean packet loss of reliable
packets as a ratio with respect to the constant ENET_PEER_PACKET_LOSS_SCALE
*/

That only monitors reliable traffic, though.



On Mon, May 5, 2014 at 2:25 PM, Ola Røer Thorsen <ola at silentwings.no> wrote:

> Lee,
>
> Thank you very much for the reply.
>
> I had not realized that fragmented packets are sent as reliable. But sure
> it makes sense to me now that you mention it. I have tried using the
> unreliable fragment option, but then as you suggest almost no packets are
> received at all. So I guess what happens is that ENet is very busy
> retransmitting lost packets all the time.
>
> Is it possible to adjust the fragment size used by ENet? Maybe I can use
> larger fragments on this LAN. Are there maybe some other things one could
> tune to optimize throughput for something like this?
>
> What kind of stats could I monitor to see how many packets are still being
> sent by ENet? I recon it's found in the ENetPeer struct. I could try to
> hold off sending more packets if I detect that "the pipes get clogged up".
>
> Thanks for creating ENet in the first place, and keeping it up-to-date for
> so many years. :-)
>
> Cheers,
> Ola
>
>
> 2014-05-05 11:50 GMT+02:00 Lee Salzman <lsalzman at gmail.com>:
>
> 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.
>>
>> 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.
>>
>>
>> On Mon, May 5, 2014 at 11:49 AM, Ola Røer Thorsen <ola at silentwings.no>wrote:
>>
>>> Hi all,
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> Best regards,
>>> Ola Røer Thorsen
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20140505/273b5b70/attachment-0001.html>