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.
<br><br><div><span class="gmail_quote">On 12/27/06, <b class="gmail_sendername">intripoon</b> <<a href="mailto:intripoon@gmx.de">intripoon@gmx.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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: Discussion of the ENet library<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>
<br></blockquote></div><br>