[evaal contest] [localization] status of integration and timestamp computation

Julia Vlasenko vlasenko at ualberta.ca
Sat Jun 30 23:39:06 CEST 2012


Hi Dario and all,

With regards to the status of integration I have to say a couple of things:
in general our system successfully communicates with the provided socket
server and receives events from the device simulator as well. However, I
have observed some weird situations when the the device simulator client
cannot connect to the server. More specifically, these situations occur
only when I have to restart the device client after my own client has
already been connected to the server, and the server has generated a thread
for my client. At this point, if I restart the device simulator, the server
fails to register this new client (which is confirmed by the server log -
there is no indication of a new client connection). I am wondering whether
other competitors have encountered a similar problem.

I understand that during the competition the device simulator will not be
used as it is, that is, domotic bus events generation and the socket server
might be incorporated in one processing unit and therefore there won't be a
problem of reconnecting clients. However, if this is not the case, and
every physical device connects to the server as a separate client, I would
like to be reassured that our system won't be missing any contextual events
due to the issue with clients reconnections.

Another question relevant to the integration: will we be given the unique
IDs of the domotic bus devices before the competition? I am asking because
in order to make the integration of our system with the domotic bus more or
less transparent, we need to register these additional devices in our
system in compliance with the specifications used for our own devices. At
the very least, we need to make sure that all the ids are unique so if we
don't know the ids of your devices in advance, we might have collisions. If
you choose not to disclose the ids of your devices since you have already
provided the coordinates, it's fine with us too because we can assign our
own ids and upon receiving events from the domotic bus, we'll simply infer
those ids from the provided coordinates.

After reading one of the recent digests, I am not sure I understand what
timestamp is meant here:

>
> the time stamp is really used in the metrics is the one that is created
> where the integration program is running.
> This timestamp is automatically computed locally using the computer's
> clock. For this reason, the only machine that must be synchronised with
> the NTP client is the one runnning the integration program (the socket
> server or the itnegrated java package).
>

I believe that this information applies to java-based systems only,
otherwise it's rather confusing. We are using a second option for
integration - communication over sockets. As far as I understand,
competitors do NOT run the socket server in their systems during the
competition - our system acts as a telnet client which publishes
localization tuples to/reads contextual events from the server provided by
the organizers at the given ip address. I did not read any details of java
integration but the above explanation sounds like the java package
calculates its own timestamps when sending a tuple to the socket server.
This is NOT the case for our system because the timestamps reported by our
system will be delayed compared to the time when they are actually
published. Our computer which acts as a telnet client and publishes the
tuples will be ntp synchronized prior to the beginning of the tests and the
timestamps will be reported in epoch time with milliseconds so that there
is no issue of conversion from relative time. Please let me know if my
understanding is correct.

One more thing I would like to know is how the "half a second" parameter is
exactly measured. In the case of our system where the delayed timestamps
are reported, there are two options: 1) to keep the log of when the tuples
are published to the server socket and measure the time difference between
each two consecutive published tuples; 2) measure the difference between
two consecutive timestamps taken from the actual tuple. Depending on which
calculation scheme is used, we need to make appropriate arrangements in the
code. Also, how strict is this requirement, is it expected to be 500ms
sharp or some deviations within reasonable number of milliseconds are
allowed?

Thank you,
Julia Vlasenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://evaal.aaloa.org/pipermail/contest/attachments/20120630/34dd454d/attachment.html>


More information about the Contest mailing list