[robocup-small] New Referee Box Protocol

[Ben Johnson]

I am in favor of using integers for time.
If we use floating-point seconds, we have a potential rounding error
because we need so much dynamic range.  Because 1e-6 can't be represented
exactly in a float64, adding one microsecond to a time produces an
incorrect result (see the demonstration code below).

If we use floating-point microseconds, that is no better than integer
microseconds, but with a less elegant implementation.  Vision uses integer
microseconds in a uint64, and timing matters much more for vision than for
referee messages.

A double doesn't give significantly better resolution than one microsecond
(less than two bits), and since it can't actually represent one microsecond
exactly, I would argue that it's worse.  It introduces rounding error
without any advantage.
Referee messages except for time remaining are inherently high-latency,
because they pass through two humans before they reach the computer.
 Extremely high precision is not necessary.
If for some reason we actually need better resolution, I would suggest
adding more bits as another field.  The purpose of floating-point formats
is to provide a variable exponent, which we don't need here.

It's easy to convert to a double on the receiving side, but it's hard to
fix rounding errors after the fact.  I would rather see the time exactly as
the OS originally gave it.

Rounding demonstration:
#include <stdio.h>
#include <sys/time.h>

int main()
{
    struct timeval tv;
    gettimeofday(&tv, 0);

    double t0 = tv.tv_sec + tv.tv_usec * 1.0e-6;
    double t1 = t0 + 1.0e-6;
    printf("%g\n", t1 - t0);

    return 0;
}

On Fri, Nov 9, 2012 at 11:49 AM, Christopher Head <chead at chead.ca> wrote:

> Thanks for the comments! With respect to using floating point instead
> of integer timestamps, I don’t see much point (NTP is unlikely to get
> much better than millisecond synchronization anyway), but there’s really
> no reason not to either. If you want FP, and nobody else says anything,
> I’ll go with FP.
>
> With respect to using TCP, I disagree. I think UDP actually suits our
> situation better. First, UDP allows us to use multicast so all the
> teams receive the packet at exactly the same time; TCP would require us
> to rotate between the teams and send updates to them one at a time.
> Second, TCP would require us to maintain a collection of sockets and
> handle new and closing connections, increasing code complexity. This
> would also introduce the need to start up the referee box and the
> teams’ AIs in the proper order (presumably refbox first), whereas
> today, those can be started in any order and the refbox can even be
> restarted while a team’s AI is running. Third, I believe TCP would
> actually give us exactly the same level of reliability but with lower
> performance: in TCP, if a packet is dropped, you have to wait for the
> timeout to expire before it’s resent. The current referee box protocol,
> and the one I proposed, just send the UDP packets unconditionally at a
> fixed frequency. This means you already have automatic resending to
> deal with dropped packets, and the longest time you can possibly wait
> is 100 ms (and we could reduce this if we wanted). With TCP, you would
> have to wait for the retransmit timeout before getting the data.
> Finally, TCP gives you a byte stream while UDP maintains message
> boundaries, so with TCP we would have to add length prefixes, making
> both the sending and receiving code more complex.
>
> Are you aware of any problems that UDP has caused with either the
> referee box or SSL-Vision? I personally haven’t seen any problems.
>
> Chris
>
> On Fri, 9 Nov 2012 09:27:46 -0500
> Joydeep Biswas <joydeep at cmu.edu> wrote:
>
> > Hi Chris & the rest of the TC,
> >
> > It's good to see the referee protocol be modernized. I have a couple
> > of recommendations:
> >
> > 1. The time stamp should be a double precision float (float64), in
> > terms of epoch time in seconds. This will allow precision of up to
> > fractions of microseconds (see calculation [1]), and can be used for
> > time comparisons much more easily. Code for GetTimeSec() in [2]. These
> > time stamps are only as meaningful as the synchronization of the
> > clocks between the computers. Therefore, I recommend that the referee
> > computer be configured to run ntpd. Teams can then sync times with the
> > referee.
> >
> > 2. We should move to TCP. The additional couple of microseconds of
> > latency is a minuscule price to pay for the reliability gain.
> >
> > Regards,
> > Joydeep
> >
> > [1] Current epoch time in seconds (only order of magnitude important),
> > divided by 2^(mantissa bits) =  1352471098 / (2^52) = 0.3 usec
> >
> > [2]
> > double GetTimeSec() {
> >   timespec ts;
> >   clock_gettime(CLOCK_REALTIME,&ts);
> >   return( static_cast<double>(ts.tv_sec) +
> > static_cast<double>(ts.tv_nsec)*(1.0E-9));
> > }
> _______________________________________________
> robocup-small mailing list
> robocup-small at cc.gatech.edu
> https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cc.gatech.edu/pipermail/robocup-small/attachments/20121109/78cbc3ef/attachment.html>