[ENet-discuss] peer->roundTripTime

[Kevin Gadd]

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.)

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.

On 12/27/06, intripoon <intripoon at gmx.de> wrote:
>
> Hi!
>
> I know about that. Actually, my program doesn't do much more than
> servicing
> enet, sending a packet once per second and print out the rtt every 5
> seconds.
>
> What I do is get the system time in microseconds by using the
> PerformanceCounter, put that value in a packet and send it to the other
> peer, which again gets the system time in microseconds using the
> PerformanceCounterr. The difference is about 300 microseconds, averaged
> over
> a few interations. So it actually takes about 300 microseconds to send a
> packet from one peer to another on the same pc, in two different
> processes.
> At the same time, the rtt returned by enet is 7 milliseconds, telling me
> the
> averaged time for a packet transmission is 3500 microseconds. Factor 10
> off?!?
>
> I didn't know of http://enet.bespin.org until Bjorn's post. Googleing for
> enet results in the cubrik page for me. However, I downloaded the 1.0 from
> the bespin page and it is probably newer because some files are larger
> than
> in my previous version. The issue described above is the same in both
> versions though.
>
> The reason why I'm curious about it is because I planed to use the rtt
> value
> to correct time differences between the peers. But a 6.5 ms error on
> localhost is too much for my application. I could send packets containing
> timestamps between the peers and calculate the rtt and the time correction
> myself. However, that'ld require to send additional packets. The
> possibility
> to use all packets sent to calculate the rtt has to be done in enet's
> layer
> - or I would have to introduce another layer on top of enet adding the
> required information to each packet. But all this is already done in enet,
> but for some reason it seems to be quite unprecise. Any idea why?
>
> Best regards
>         Marc
>
>
> -----Ursprüngliche Nachricht-----
> Von: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org
> ]
> Im Auftrag von Lee Salzman
> Gesendet: Mittwoch, 27. Dezember 2006 17:37
> An: Discussion of the ENet library
> Betreff: Re: [ENet-discuss] peer->roundTripTime
>
> Remember, ENet does pretty much all work in enet_host_service(). So if
> you aren't constantly servicing the host, then the frequency at which
> you call it is going to have a small effect on RTTs. It's never been a
> big deal in so far as what ENet's designed for.
>
> Lee
>
> intripoon wrote:
> > Hi !
> >
> > I wonder about the peer->roundTripTime value. Between every pc in my
> local
> > network, all peers have a roundTripTime of 7 to each other, no matter
> what
> I
> > do. Shouldn't that be value be smaller? Even on one pc having two
> processes
> > connecting to each other by enet peers, that value is 7. I also tried
> > sending a high performance counter value from one process to the other
> to
> > check if it really takes 3.5 ms to send a packet - but it doesn't.
> >
> > Somewhere I read, the rtt value is computed by comparing the time of a
> > reliably sent packet and it's returning ack packet. Do maybe ack packets
> get
> > delayed for some reason? Maybe waiting for more possible ack packets to
> be
> > sent? Maybe something like that explains the 7 ms?
> >
> > Is there a way to configure enet to return a more correct value in this
> > case?
> >
> > I'm not quite sure which version of enet I'm using. Is there a version
> > string somewhere? It's not too old though.
> >
> > Best regards
> >       Marc
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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/20061227/1915a636/attachment-0001.html