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

[Ola Røer Thorsen]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20140505/f71375d0/attachment.html>