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

[Lee Salzman]

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