[Tinyos-devel] problem of using FTSP and CTP

[Philip Levis]

On Mar 20, 2009, at 4:25 PM, Miklos Maroti wrote:

> Guys,
>
> On Sat, Mar 21, 2009 at 12:00 AM, Branislav Kusy  
> <kusy at stanford.edu> wrote:
>> there is a bug in CTP that causes CTP to hang forever, if any other
>> component wires ActiveMessageC (rather than AMSenderC). described  
>> in this
>> thread:
>> http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008- 
>> December/003513.html
>
> Ok, I read that thread, and I think Phil's conclusion (and the comment
> about subsendResult == EBUSY) is incorrect. I think the AMSend
> interface can return EBUSY even if a prior send was not called (not
> from this AMSend interface but from another one with a different am
> type). This is exactly what happens when some other component uses
> ActiveMessageC instead of the AMSenderC (which serializes access).
>
> So CTP need to be fixed and handle the EBUSY case.
>
>> FTSP is one such components, thus CTP will hang when used with  
>> FTSP. one
>> option would be to write system/AMTimeSyncSenderC.nc component  
>> that provides
>> the TimeSyncAMSend interface that FTSP needs. i don't like this  
>> solution as
>> there start to be too many timesync related files that mirror the  
>> radio
>> stack files. perhaps the timestamping code should be redesigned?  
>> fixing the
>> CTP bug would also help ;)
>
> It would be (probably) impossible to write your AMTimeSyncSenderC
> component, since it has to use the TimeSyncActiveMessageC to send
> messages. We cannot implement the TimeSync protocol as a mix-in
> protocol (such as PacketLink) because on the receiver side we have
> absolutely no information if we have received a message with an
> embedded time sync data or not, since only a 32-bit value is appended
> and no flag is set in the message body. The only information we have
> is the AM type, so we rely on the user to wire components through the
> TimeSyncActiveMessageC when needed.
>
> (One solution would be to wire the TimeSyncActiveMessageC to AMSenderC
> on the sender side, but I am not sure we want to do that).
>

Packet senders shouldn't wire to ActiveMessageC.Send. It forces *all*  
senders to handle EBUSY on a virtualized interface, adding  
unnecessary code. It breaks scheduling fairness. The hack in 1.x to  
deal with this was a global sendDone event; let's not go back down  
that path.

Or is the issue that there should be a TEP saying that if anything in  
your system uses AMSenderC.Send you MUST NOT wire to  
ActiveMessageC.Send?

Phil