[ENet-discuss] peer->roundTripTime

Wed Dec 27 16:56:36 PST 2006

Hi again!

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.

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?

Best regards

            Marc

  _____  

Von: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
Im Auftrag von Kevin Gadd
Gesendet: Mittwoch, 27. Dezember 2006 20:17
An: Discussion of the ENet library
Betreff: Re: [ENet-discuss] peer->roundTripTime

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/20061228/f46e9011/attachment.htm 