[Tinyos-devel] Fwd: timestamps in seriallisten/sflisten etc.

[Vlado Handziski]

Uhh. Is there a way to make Reply All default in Gmail? :)

Vlado

---------- Forwarded message ----------
From: Vlado Handziski <handzisk at tkn.tu-berlin.de>
Date: Fri, Jun 27, 2008 at 00:00
Subject: Re: [Tinyos-devel] timestamps in seriallisten/sflisten etc.
To: Philip Levis <pal at cs.stanford.edu>


On Thu, Jun 26, 2008 at 23:32, Philip Levis <pal at cs.stanford.edu> wrote:

>
> I'd argue that this approach should also invert, so packet formats are
> symmetric; packets sent to a source have a timestamp, and then the
> source decides whether to strip it. Otherwise you get into a funny
> case where the send and receive paths take different types, making
> things like simple echo programs more complex.
>
> This completely avoids the question Vlado raises. Serial protocol IDs
> don't decide whether someone has to timestamp. This seems kind of
> weird -- why is the mote telling the PC what to do? Instead, the PC-
> side code decides whether it wants to timestamp. It's just that the
> packet and message libs assume the packets have timestamps.
>
>
Because  I actually want that timestamp to represent the time the packet was
sent on the mote side and not when it was received by the PC side. I want a
packet fromat that will allow the mote to insert a stamp before sending it
to the PC. The PC checks the type and corrects the stamp translating it into
local representation of the time it was sent by the mote. The delay over the
serial line + the usb_to_serial driver, etc., especially in cases like in
our testbed where we have chais of active USB cables, hubs with up to 8
devices, etc. is non negligible.  Once this very variable delay is factored
out, plain old NTP sync over a set of distribited SFs hosts is enough to
achieve precision allowing one to track causality relationships between the
events received on the different SFs, without using any time sync protocol
on the mote side.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080627/8a02b71b/attachment.htm