[Tinyos Core WG] arbiter issues

[Joe Polastre]

> > This then implies that all chips with radios must support 32kHz
> > precision to be TinyOS 2.x-compliant.  What is the width of the
> > timestamp?  32-bits?  16-bits is only a 2 second duration, so that
> > implies that the radio stack will not delay the timestamp by more than
> > 2 seconds when dispatching to higher layers
> Yes.

Can you give a reason why 32-bits is not acceptable (as compared to 16-bits)?

> > , something that may or may
> > not be possible based on platform, tasks, etc.
> Are you serious?

Yes, I am serious.  Can you guarantee that a task will not be delayed
for longer than this period?  Can you assure me that 2 seconds is not
exceeded?  I think not.  If you can, I welcome a proof of
completeness.

> > Timestamping on receive is only half the battle; it is the
> > reconciliation of transmit and receive stamps that reconcile timing
> > differences between nodes.  Are you suggesting that T2 not initially
> > support this in a single packet reception but rather require multiple
> > packet transmissions to establish a common time base?
> Agreed. The point is that these are values which stacks already
> collect and so should be made available. This is different than
> providing a meaningful full time synchronization service, which I
> think would be inadvisable to require stacks to do. It would be
> exactly the kind of thing that an additional interface would provide.

Without both pieces of information, the timestamping service is fairly
useless.  Boomerang identifies a time base and precision that others
can use to establish time synchronization bounds that are not
unreasonable.  You're asking for a piece of information to be
available that is already part of the stack---I argue that this is NOT
already part of the stack and rather is an artifact of the stacks that
we use (please tell me how to implement this interface, including
timestamps, on the BTnode!).

I want timestamping information in packets, but Boomerang provides a
nice compromise--select the packets that you want timestamping based
on service identifier and then use these messages to establish global
time standards.

-Joe