[Tinyos-devel] RE: time sync interfaces

[Janos Sallai]

Hi Miklos,

I like it. Functionally, I think, this is what we need.

PacketTimeStamp is a set of accessors/mutators for the two metadata
fields: the timestamp and the flag that specifies if the timestamp is
valid. Maybe, just to make things clear for everybody, we could put
another flag in there which is 0 if the timestamp is a rx timestamp and 1
if it's a tx timestamp. This would also make sure that multiple components
modifying the metadata be aware of each other's actions. What do you
think?

Concerning PacketTimeSync: This one defines accessors/mutators that
operate on the timestamp within the message footer. Here, I'd make a
couple of things settable by metadata flags.
1. behavior of timestamping on transmission:
  1a) write the local time of transmission into footer.timestamp, or,
  1b) write the difference of the local time of transmission and the value
      that's already in there
2. behavior on the receiver side:
  2a) do not modify
  2b) write the difference of the local time of reception and the value
      received in footer.timestamp to footer.timestamp

The (1a,2a) mode will be pretty much clear for everybody: after a message
is sent, the sender will see the time of transmission in footer.timestamp
(as well as in metadata.timestamp). On the receiver side, after a message
is received, footer.timestamp will contain the time of transmission per
the transmitter's local clock. Metadata.timestamp will contain the time of
transmission per the receiver's local clock. The difference of the two can
be used to convert any number of event timestamps (given per the
transmitter's local clock) that are in the payload.

Of course, you waste sizeof(size_type) bytes in the payload if you want to
implement FTPS this way. Similarly, you waste sizeof(size_type) bytes if
you want to do ETA with just one event timestamp per message. But this way
it's possible to do ETA with multiple events.

In (1b,2b) mode, both FTSP and ETA can be implemented without having any
extra information in the payload.

(1a,2b) is also suitable for ETA with multiple event timestamps in the
payload. There's a chance that (1b,2a) would have some use cases, as well.
(firefly-inspired synchronization?)

I think that adding these two flags, with (1a,2a) as the default, would
make things more clear for people who are not too familiar with
timestamping. The options 1b and 2b would make it possible to implement
existing protocols with minimal payload overhead.

What's your opinion?

Janos

-----Original Message-----
From: mmaroti at gmail.com [mailto:mmaroti at gmail.com] On Behalf Of Miklos
Maroti
Sent: Tuesday, November 06, 2007 3:56 AM
To: Janos Sallai
Subject: Fwd: time sync interfaces

Hi Sly,

Did you get this email?

Miklos

---------- Forwarded message ----------
From: Miklos Maroti <mmaroti at math.u-szeged.hu>
Date: Nov 4, 2007 11:24 PM
Subject: time sync interfaces
To: TinyOS Core WG <tinyos-2.0wg at mail.millennium.berkeley.edu>


Dear All,

I put together a proposal for the time sync interface for T2.
Actually, I propose two interfaces, one from receiver-receiver time
synchronization (the time stamp does not need to be embedded into the
message), and sender-receiver time synchronization. Both interfaces
take a precision tag and size parameter. I am very strongly for 16-bit
time synch implementation inside the radio drivers so we do not have
to juggle with 32-bit numbers for backoff and stuff and can have a
single notion of time inside the driver. Both interfaces are designed
so that it is trivial to implement 16->32 bit extensions, and the
precision could also be changed without much difficulties. I think the
two interfaces should not be merged into a single one because they are
fundamentally different. Here are the interfaces:

interface PacketTimeStamp<precision_tag, size_type>
{
 /**
  * Returns TRUE if the time stamp stored in the message is valid. Under
  * special circumstances the radio chip might not be able to correctly
  * assign a precise time value to an incoming packet (e.g. under very
  * heavy traffic multiple interrupts can occur before they could be
  * serviced, and even if capture registers are used, it is not possible
  * to get the time stamp for the first or last unserviced event), in
  * which case the time stamp value should not be used.
  */
 async command bool isSet(message_t* msg);

 /**
  * Return the time stamp for the given message. Please check with the
  * isSet command if this value can be relied upon. If this command is
  * called after transmission, then the transmit time of the packet
  * is returned (the time when the frame synchronization byte was
  * transmitted). If this command is called after the message is received,
  * the tne receive time of the message is returned.
  */
 async command size_type get(message_t* msg);

 /**
  * Sets the isSet flag to FALSE.
  */
 async command void clear(message_t* msg);

 /**
  * Sets the isSet false to TRUE and the time stamp value to the
  * specified value.
  */
 async command void set(message_t* msg, size_type value);
}

interface PacketTimeSynch<precision_tag, size_type>
{
 /**
  * This command should be called by the sender on packets used for
sender-
  * receiver time synchronization. The eventTime parameter should be as
  * close to the current time as possible (precision and size of the stamp
  * permitting) to avoid large time synchronization errors resulting from
  * the time skew between the clocks of the sender and receiver. The
  * time difference between the sending time and eventTime is stored in
  * the message just before it is transmitted over the air.
  */
 async command void set(message_t* msg, size_type eventTime);

 /**
  * The recveive should call this method to ensure that the received time
  * stamp is correct (for the same reason as for PacketTimeStamp.isSet).
  * If this method returns TRUE, then the eventTime returned by the get
  * command is correct.
  */
 async command bool isSet(message_t* msg);

 /**
  * This command should be called by the receiver. The time stamp of the
  * received message is added to the embedded time difference to get the
  * eventTime as measured by the clock of the receiver. The caller should
  * call the isSet command before to make sure that the returned time is
  * correct.
  */
 async command size_type get(message_t* msg);
}

One remaining issue is where to store the embedded time stamp.
Probably it should go into the footer, but then we might need another
Send/Receive interface for time stamped messages? What do you think
about this? Also, I am happy to forward this to the devel list, as I
think many people would have some say in it.

Best,
Miklos

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.22/1112 - Release Date:
11/5/2007 7:11 PM

-------------- 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/20071106/a6a58e01/smime.bin