<div dir="ltr"><font><font face="tahoma,sans-serif"><font>Hi All,<br><br><font>Thank you <font>Chris f<font>or taking care o<font>f this<font>. I have a co<font>uple of recommendations<font><font>:</font><br><br><font><font><font>I th<font>ink it is better to add </font></font>"Team Name" <font>as a string to the <font>"</font>TeamInfo<font>" message<font> and extend <font>RefBox software <font>to<font> <font>facilitate</font> </font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>setting th<font>ese</font> values. This can be hel<font>pful for both<font><font><font> logging </font></font></font></font>and external match state displa<font>y programs<font> that may be use<font>d <font>during <font><font>competitions</font>.</font></font></font></font></font><br>
<br><font><font><font><font>There is a C++ class inside the current referee box <font>so<font>urce packa<font>ge (called <font>GameState <font>as far as I can rem<font>ember) that ca<font>n</font> <font>interpret</font> the </font></font></font></font></font></font></font></font></font></font>current refbox <font>protocol<font>. I think it wo<font>uld be great if <font>a similar <font>int<font>erpret<font>ion <font>facility </font></font></font></font></font></font></font>is provided <font>for the new protocol. </font></font><br>
<br><font>I also agree with Joydeep's<font> first suggestion regarding using float64<font>.<br><br><font>Cheers,<br><font>Mani</font><br></font></font></font></font><br></div><div class="gmail_extra"><br clear="all">
Mani Monajjemi<br>
<br><br><div class="gmail_quote">On Fri, Nov 9, 2012 at 11:49 AM, Christopher Head <span dir="ltr"><<a href="mailto:chead@chead.ca" target="_blank">chead@chead.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the comments! With respect to using floating point instead<br>
of integer timestamps, I don’t see much point (NTP is unlikely to get<br>
much better than millisecond synchronization anyway), but there’s really<br>
no reason not to either. If you want FP, and nobody else says anything,<br>
I’ll go with FP.<br>
<br>
With respect to using TCP, I disagree. I think UDP actually suits our<br>
situation better. First, UDP allows us to use multicast so all the<br>
teams receive the packet at exactly the same time; TCP would require us<br>
to rotate between the teams and send updates to them one at a time.<br>
Second, TCP would require us to maintain a collection of sockets and<br>
handle new and closing connections, increasing code complexity. This<br>
would also introduce the need to start up the referee box and the<br>
teams’ AIs in the proper order (presumably refbox first), whereas<br>
today, those can be started in any order and the refbox can even be<br>
restarted while a team’s AI is running. Third, I believe TCP would<br>
actually give us exactly the same level of reliability but with lower<br>
performance: in TCP, if a packet is dropped, you have to wait for the<br>
timeout to expire before it’s resent. The current referee box protocol,<br>
and the one I proposed, just send the UDP packets unconditionally at a<br>
fixed frequency. This means you already have automatic resending to<br>
deal with dropped packets, and the longest time you can possibly wait<br>
is 100 ms (and we could reduce this if we wanted). With TCP, you would<br>
have to wait for the retransmit timeout before getting the data.<br>
Finally, TCP gives you a byte stream while UDP maintains message<br>
boundaries, so with TCP we would have to add length prefixes, making<br>
both the sending and receiving code more complex.<br>
<br>
Are you aware of any problems that UDP has caused with either the<br>
referee box or SSL-Vision? I personally haven’t seen any problems.<br>
<br>
Chris<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, 9 Nov 2012 09:27:46 -0500<br>
Joydeep Biswas <<a href="mailto:joydeep@cmu.edu">joydeep@cmu.edu</a>> wrote:<br>
<br>
> Hi Chris & the rest of the TC,<br>
><br>
> It's good to see the referee protocol be modernized. I have a couple<br>
> of recommendations:<br>
><br>
> 1. The time stamp should be a double precision float (float64), in<br>
> terms of epoch time in seconds. This will allow precision of up to<br>
> fractions of microseconds (see calculation [1]), and can be used for<br>
> time comparisons much more easily. Code for GetTimeSec() in [2]. These<br>
> time stamps are only as meaningful as the synchronization of the<br>
> clocks between the computers. Therefore, I recommend that the referee<br>
> computer be configured to run ntpd. Teams can then sync times with the<br>
> referee.<br>
><br>
> 2. We should move to TCP. The additional couple of microseconds of<br>
> latency is a minuscule price to pay for the reliability gain.<br>
><br>
> Regards,<br>
> Joydeep<br>
><br>
> [1] Current epoch time in seconds (only order of magnitude important),<br>
> divided by 2^(mantissa bits) = 1352471098 / (2^52) = 0.3 usec<br>
><br>
> [2]<br>
> double GetTimeSec() {<br>
> timespec ts;<br>
> clock_gettime(CLOCK_REALTIME,&ts);<br>
> return( static_cast<double>(ts.tv_sec) +<br>
> static_cast<double>(ts.tv_nsec)*(1.0E-9));<br>
> }<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
robocup-small mailing list<br>
<a href="mailto:robocup-small@cc.gatech.edu">robocup-small@cc.gatech.edu</a><br>
<a href="https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small" target="_blank">https://mailman.cc.gatech.edu/mailman/listinfo/robocup-small</a><br>
</div></div></blockquote></div><br></div>