No subject
Sat May 2 20:29:37 PDT 2009
someone can spot something wrong.
Currently I've been seeing delays up to 6 seconds on some messages we are
sending. It doesn't happen all the time however it happens sporadically. We
have enet's flow control turned off. Note the unreliable messages are just
as important as the reliable messages. When we see it roundtriptime will
spike for a second and then go back to normal when it finishes.
We use roundtriptime from enet to resend unreliable packets (with updated
information) when we don't get an acc back. We cap this to .5seconds (ie if
latency is above this then we send it again anyway).
I've a feeling its related to message flooding. Normally our transmission
is about 4kbits per second but can spike to 10kbits per second (note the
data I have is averaged so I don't know the worst case).
We use both unreliable and reliable messages. Our unreliable messages are
set to a maximum packet size of 1kbytes which can be hit some times. Is
1kbyte a good size? What size have people found to be optimal for lowest
latency sending of messages.
Also what is a good rate to send/receive the packets at?
Is it possible tht enet is throwing away unreliable packets if it can't send
them? Is it possible to know when this happens so I can handle it?
Out users machines are standard everyday PCs with standard internet
connections (ie 256down and 64up). However we even see problems on faster
connections as well. On really high bandwidth/low latency connections we
don't see the issue.
Any tips?
------=_NextPart_000_0114_01C9DD23.C8F05FC0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16825" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hm, if the unreliable messages are important, =
and you're=20
sending updated packets if not acknowledged, it sounds =
like:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>1. You're thinking they really ought to be=20
reliable</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>2. You're handling them as unreliable, since =
you're=20
resending with new information anyway.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Why not skip checking ACK's, since you're not =
really using=20
that anyway? And just send out info every 0.5 =
seconds?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Not sure about the 6 secs delay; perhaps by =
default a=20
reliable re-send timeout is 5000 ms. Although if you get unack'd packets =
upon=20
packets you might overflow the pipe (but that won't happen=20
quickly).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D953372708-25052009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Ruud</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Dnl dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>Van:</B> =
enet-discuss-bounces at cubik.org=20
[mailto:enet-discuss-bounces at cubik.org] <B>Namens </B>Joel=20
Anderson<BR><B>Verzonden:</B> Monday, May 25, 2009 =
07:13<BR><B>Aan:</B>=20
enet-discuss at cubik.org<BR><B>Onderwerp:</B> [ENet-discuss] Packet =
loss,=20
unreliable packets<BR></FONT><BR></DIV>
<DIV></DIV>Hi,
<DIV><BR></DIV>
<DIV>I'm wondering if people can share =
there experiences with packet=20
loss or large delays in transmission they've had with enet =
and how=20
they solved it?</DIV>
<DIV><BR></DIV>
<DIV>From here on I'm going to try provide as much info as possible in =
case=20
someone can spot something wrong.</DIV>
<DIV><BR></DIV>
<DIV>Currently I've been seeing delays up to 6 seconds on some =
messages we are=20
sending. It doesn't happen all the time however it =
happens <SPAN=20
class=3DApple-style-span=20
style=3D"FONT-FAMILY: Arial; WHITE-SPACE: pre; BORDER-COLLAPSE: =
collapse; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px">sporadically.=20
We have enet's flow control turned off. Note the unreliable messages =
are just=20
as important as the reliable messages. When we see it roundtriptime =
will spike=20
for a second and then go back to normal when it finishes.</SPAN></DIV>
<DIV><SPAN class=3DApple-style-span=20
style=3D"WHITE-SPACE: pre; BORDER-COLLAPSE: collapse; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px"><BR></SPAN></DIV>
<DIV><SPAN class=3DApple-style-span=20
style=3D"WHITE-SPACE: pre; BORDER-COLLAPSE: collapse; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px">We=20
use roundtriptime from enet to resend unreliable packets (with updated =
information) when we don't get an acc back. We cap this to .5seconds =
(ie if=20
latency is above this then we send it again anyway).</SPAN></DIV>
<DIV><BR></DIV>
<DIV>I've a feeling its related to message flooding. Normally =
our=20
transmission is about 4kbits per second but can spike to 10kbits per =
second=20
(note the data I have is averaged so I don't know the worst =
case). </DIV>
<DIV><BR></DIV>
<DIV>We use both unreliable and reliable messages. Our =
unreliable=20
messages are set to a maximum packet size of 1kbytes which can =
be hit=20
some times. Is 1kbyte a good size? What size have people =
found to=20
be optimal for lowest latency sending of messages.</DIV>
<DIV><BR></DIV>
<DIV>Also what is a good rate to send/receive the packets at?</DIV>
<DIV><BR></DIV>
<DIV>Is it possible tht enet is throwing =
away unreliable packets if=20
it can't send them? Is it possible to know when this happens so =
I can=20
handle it?</DIV>
<DIV><BR></DIV>
<DIV>Out users machines are standard everyday PCs with standard =
internet=20
connections (ie 256down and 64up). However we even see problems =
on=20
faster connections as well. On really high=20
bandwidth/low latency connections we don't see the =
issue.</DIV>
<DIV><BR></DIV>
<DIV>Any tips?</DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0114_01C9DD23.C8F05FC0--
More information about the ENet-discuss
mailing list