[Tinyos-devel] Re: [Tinyos Core WG] time sync interfaces

[Janos Sallai]

I like the idea of timestamping all messages. In most cases, those two
bytes are not that big of an overhead, anyway. And this allows time
synchronization algorithms to collect e.g. skew information by examining
the timestamps in arbitrary messages (in a pass-through component). If the
user needs those extra two bytes, timestamping could be disabled by
returning FAIL in the isTimeSyncPacket event, as David and Phil suggests.
This has the advantage that the user has no chance to mess up the radio
stack by enabing timestamping, since it's always on. On the other hand,
disabling it by including "extensive" computation in the event handler
could cause problems.

I am kind of undecided about allowing the message_t parameter. I am not
sure that leaving it out would discourage the users from doing complex
operations. Since most probably the PacketTimeSync and AMSend will be
implemented by the same module, these users would want evaluate an
expression on the last sent message_t* within the isTimeSyncPacket event
handler.

If we decide on keeping the message_t*, I would make the contents of the
message read-only:

interface PacketTimeSync {
   async event bool isTimeSyncPacket(message_t* const msg);
}

Janos

-----Original Message-----
From: tinyos-devel-bounces at millennium.berkeley.edu
[mailto:tinyos-devel-bounces at millennium.berkeley.edu] On Behalf Of Philip
Levis
Sent: Thursday, December 13, 2007 12:38 PM
To: David Gay
Cc: TinyOS Development; Miklos Maroti
Subject: Re: [Tinyos-devel] Re: [Tinyos Core WG] time sync interfaces


On Dec 13, 2007, at 10:29 AM, David Gay wrote:
>>
>
> This also has the disadvantage that the corresponding 1.x interface
> had: excessive processing in a lastTouch implementation can break the
> radio stack, i.e. on some radio stacks the place where lastTouch would
> be called is very timing sensitive. "Excessive processing" may not be
> much processing btw (I think the example from 1.x involved a few
> 32-bit arithmetic operations).
>
> An alternate proposal would be:
>
> interface PacketTimeSync
> {
>     async event int8_t isTimeSyncPacket();
> }
>
> which would be:
> - offered as a parameterized-by-amid interface (like PacketLastTouch)
> - called from the radio stack at the "last possible moment"
> - if isTimeSyncPacket returns -1, nothing happens
> - if isTimeSyncPacket returns X (>= 0), a time stamp is stuffed in the
> packet at offset X
>
> The idea is:
> - to make it easy to only put time stamps in some packets, with no
> header overhead
> - to discourage users from doing anything fancy within a critical part
> of a radio stack - normally they should just do something like return
> a constant (or maybe a variable's value) from isTimeSyncPacket - this
> is why there's no message_t parameter...
>
> There's a few obvious issues:
> - what's the width/precision/etc of the timestamp (maybe
> PacketTimeSync should be a generic interface, with appropriate type
> parameters, presumably matching the radio stack's PacketTimeStamping
> interface)
> - how do you get the right offset in isTimeSyncPacket?
> - isTimeSyncPacket could be split into two events (one for the
> question, the other for the offset)
>

This is getting closer, I think, but it embedding the timestamp at an
arbitrary offset is not feasible for many packet-based radios. That
is, if you have to spool the packet to the radio prior to
transmission, it's often easy to append a few bytes, but changing
bytes early in the packet could be problematic. So if it were

interface PacketTimeSync {
   async event bool isTimeSyncPacket();
}

that might work better.

All of David's comments on arbitrary event handlers are well taken;
Sam beat his head against this problem for a week in TinyDB (shifting
from a 16-bit to 32-bit timestamp caused the stack to fail), and
Jeongyeup Paek re-encountered the exact same problem recently (Nov 4.
to -help).

Phil
_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.1 - Release Date: 12/11/2007
12:00 AM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3096 bytes
Desc: not available
Url : https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20071213/f58ef0a8/smime.bin