<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi again!<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>There is no problem with time going forth
and back a bit in my application. Precision is more important. I could send
packets for time synchronization myself as you and I wrote before. But, using
enet’s rtt to correct the time has one benefit: Every packet that gets
sent (reliable) helps in synchronizing the time. That’s a lot time
correcting info without additional traffic. But if the precision isn’t
high enough, I’ll go with sending additional packets anyways. I’m
not sleeping btw, instead let enet do the sleeping by waiting for some time for
new packets.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I had a rough lock at enet’s source.
The variance values, are they actual variances or just values that behave
somehow like variances? The way the rtt gets “averaged” also looks
interesting. Are these mathematical equivalents to average and variance or is
there some other theoretical background behind these? Or are they just working?<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Best regards<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> Marc<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=DE style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=DE style='font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>Von:</span></font></b><font size=2
face=Tahoma><span lang=DE style='font-size:10.0pt;font-family:Tahoma'> enet-discuss-bounces@cubik.org
[mailto:enet-discuss-bounces@cubik.org] <b><span style='font-weight:bold'>Im
Auftrag von </span></b>Kevin Gadd<br>
<b><span style='font-weight:bold'>Gesendet:</span></b> Mittwoch, 27. Dezember
2006 20:17<br>
<b><span style='font-weight:bold'>An:</span></b> <st1:PersonName w:st="on">Discussion
of the ENet library</st1:PersonName><br>
<b><span style='font-weight:bold'>Betreff:</span></b> Re: [ENet-discuss]
peer->roundTripTime</span></font><span lang=DE><o:p></o:p></span></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>If you're going to
correct time differences, you should do it manually by sending timestamp values
back and forth and computing a correction value until you can accurately
predict the current time on the other system(s). Using RTT to do this is going
to be unpredictable, since it's not designed for that purpose. The overhead of
sending the time correction packets yourself shouldn't be significant, since it
should only be necessary to correct time at the beginning of a session, or
possibly once every 15 or 30 minutes - most computer clocks will not drift
significantly enough to cause problems on the scale of a few hours, and if
you're using the processor's performance counter you shouldn't have any drift
problems whatsoever. (I also would not recommend doing time correction after
your game session begins, since adjustments to timestamps while you're going
can have unexpected consequences on your algorithms - clocks moving forward or
backward is undesirable behavior and we've personally had some really bizarre
bugs crop up as a result of it due to network time synchronization.) <br>
<br>
I suspect that your RTT would be significantly lower if you simply had
enet_host_service() in a while() loop and checked the RTT value in a critical
section in another thread. If you're using sleep or doing other work in between
service calls, you're introducing additional latency that exists on both sides,
possibly increasing your round trip time by a lot. <o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><span class=gmailquote><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>On 12/27/06, <b><span style='font-weight:bold'>intripoon</span></b>
<<a href="mailto:intripoon@gmx.de">intripoon@gmx.de</a>> wrote:</span></font></span><o:p></o:p></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Hi!<br>
<br>
I know about that. Actually, my program doesn't do much more than servicing<br>
enet, sending a packet once per second and print out the rtt every 5<br>
seconds.<br>
<br>
What I do is get the system time in microseconds by using the <br>
PerformanceCounter, put that value in a packet and send it to the other<br>
peer, which again gets the system time in microseconds using the<br>
PerformanceCounterr. The difference is about 300 microseconds, averaged over <br>
a few interations. So it actually takes about 300 microseconds to send a<br>
packet from one peer to another on the same pc, in two different processes.<br>
At the same time, the rtt returned by enet is 7 milliseconds, telling me the <br>
averaged time for a packet transmission is 3500 microseconds. Factor 10<br>
off?!?<br>
<br>
I didn't know of <a href="http://enet.bespin.org">http://enet.bespin.org</a>
until Bjorn's post. Googleing for<br>
enet results in the cubrik page for me. However, I downloaded the 1.0 from<br>
the bespin page and it is probably newer because some files are larger than<br>
in my previous version. The issue described above is the same in both<br>
versions though.<br>
<br>
The reason why I'm curious about it is because I planed to use the rtt value <br>
to correct time differences between the peers. But a 6.5 ms error on<br>
localhost is too much for my application. I could send packets containing<br>
timestamps between the peers and calculate the rtt and the time correction <br>
myself. However, that'ld require to send additional packets. The possibility<br>
to use all packets sent to calculate the rtt has to be done in enet's layer<br>
- or I would have to introduce another layer on top of enet adding the <br>
required information to each packet. But all this is already done in enet,<br>
but for some reason it seems to be quite unprecise. Any idea why?<br>
<br>
Best regards<br>
Marc<br>
<br>
<br>
-----Ursprüngliche Nachricht----- <br>
Von: <a href="mailto:enet-discuss-bounces@cubik.org">enet-discuss-bounces@cubik.org</a>
[mailto:<a href="mailto:enet-discuss-bounces@cubik.org">enet-discuss-bounces@cubik.org</a>]<br>
Im Auftrag von Lee Salzman<br>
Gesendet: Mittwoch, 27. Dezember 2006 17:37 <br>
An: <st1:PersonName w:st="on">Discussion of the ENet library</st1:PersonName><br>
Betreff: Re: [ENet-discuss] peer->roundTripTime<br>
<br>
Remember, ENet does pretty much all work in enet_host_service(). So if<br>
you aren't constantly servicing the host, then the frequency at which <br>
you call it is going to have a small effect on RTTs. It's never been a<br>
big deal in so far as what ENet's designed for.<br>
<br>
Lee<br>
<br>
intripoon wrote:<br>
> Hi !<br>
><br>
> I wonder about the peer->roundTripTime value. Between every pc in my
local <br>
> network, all peers have a roundTripTime of 7 to each other, no matter what<br>
I<br>
> do. Shouldn't that be value be smaller? Even on one pc having two<br>
processes<br>
> connecting to each other by enet peers, that value is 7. I also tried <br>
> sending a high performance counter value from one process to the other to<br>
> check if it really takes 3.5 ms to send a packet - but it doesn't.<br>
><br>
> Somewhere I read, the rtt value is computed by comparing the time of a <br>
> reliably sent packet and it's returning ack packet. Do maybe ack packets<br>
get<br>
> delayed for some reason? Maybe waiting for more possible ack packets to be<br>
> sent? Maybe something like that explains the 7 ms? <br>
><br>
> Is there a way to configure enet to return a more correct value in this<br>
> case?<br>
><br>
> I'm not quite sure which version of enet I'm using. Is there a version<br>
> string somewhere? It's not too old though. <br>
><br>
> Best regards<br>
> Marc<br>
><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">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
><br>
<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">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br>
<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">http://lists.cubik.org/mailman/listinfo/enet-discuss</a>
<o:p></o:p></span></font></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>