[Tinyos Core WG] TEP105: LowPowerListening Duty Cycles

[Janos Sallai]

David,

 

I agree with your recommendation to deprecate setLocalDutyCycle() and
setRxDutyCycle(). The interval based ones should always suffice.

 

Some other comments on TEP 105 (continuing the core wg discussion):

 

1. Cancel

 

With the current semantics of cancel (see. TEP 116), it's not possible
to write a TEP 116 compliant LPL stack that allows for cancelling after
sending has started. 

 

TEP 116 says: "The cancel command allows a sender to cancel the current
transmission. A call to cancel when there is no pending sendDone event
MUST return FAIL. If there is a pending sendDone event and the cancel
returns SUCCESS, then the packet layer MUST NOT transmit the packet and
MUST signal sendDone with ECANCEL as its error code. If there is a
pending sendDone event and cancel returns FAIL, then sendDone MUST occur
as if the cancel was not called." 

 

That is, if the radio stack returns SUCCESS to the caller of cancel, it
must guarantee that the packet is not transmitted. But once transmission
has started (packets have been transmitted but the receiver has not
necessarily woken up), this cannot be guaranteed.

 

I think TEP 105 should redefine the semantics of cancel, without the
clause that requires that the packet is not transmitted yet (or with an
error code different than ECANCEL in sendDone?).

 

2.  Send

 

The LPL TEP says that "If a message is already in the process of being
sent, multiple calls to Send should return FAIL.". This is in conflict
with TEP 116, which requires that send should return EBUSY. The LPL TEP
should require returning EBUSY as well.

 

3. Dummy LPL implementation

 

If LPL is not compiled in the radio stack, the TEP requires that calls
to LowPowerListending MUST be handled by a dummy implementation. The
rationale for this is to make app testing easy (LPL vs. non-LPL code).
If a particular radio stack doesn't have a dummy LPL implementation,
then calls to LPL commands will simply cause the app to fail to compile.
This might be a better way to inform the user that LPL is not available
than being silent and not providing the service. If a dummy
implementation is required by a particular use case, such a component
can always be implemented on top of the HIL. Also, if we're about to
change the semantics of cancel in LPL mode, it is not clear which
semantics would apply to the dummy LPL implementation...

 

Janos

 

From: tinyos-2.0wg-bounces at millennium.berkeley.edu
[mailto:tinyos-2.0wg-bounces at millennium.berkeley.edu] On Behalf Of David
Moss
Sent: Wednesday, May 14, 2008 12:57 PM
To: 'TinyOS-Devel list'; 'TinyOS Core WG'
Subject: [Tinyos Core WG] TEP105: LowPowerListening Duty Cycles

 

Is anyone using the setLocalDutyCycle() and setRxDutyCycle() functions
in the LowPowerListening interface? 

 

I see lots of problems with all duty cycle related functions in the
LowPowerListening interface:

 

Duty cycle functions are very inaccurate and difficult to maintain
because they require manual measurements to be performed on a node.  

The correct value may even vary from platform to platform, depending on
the implementation. In some cases, like hardware-driven Wake-on Radio,
it is difficult to specify a duty cycle with any degree of accuracy.

Any changes to the radio stack, including unrelated areas like
Acknowledgments, will affect the duty cycle and require the developer to
make measurements again.

The limitations on the duty cycle percentage only let you get down to
0.01%.  With the ever-increasing efficiency of receive checks, 0.01% is
not be enough.  In some implementations, I'm able to achieve numbers
like 0.0001% duty cycle or lower, which makes all duty cycle functions
obsolete.

 

Given these on-going problems with setLocalDutyCycle() and
setRxDutyCycle(), it is my opinion that the best thing we can do is
@deprecate these functions for now, leave them available for the next
release as we ease out of them, remove them from TEP105, and avoid using
them at all costs.   

 

The setRxSleepInterval() and setLocalSleepInterval() functions are much
more reliable, predictable, cross-platform compatible, and always
correct.

 

Thoughts?

 

-David

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20080514/9b8784e0/attachment-0001.htm