Hi Janos! On Thu, Dec 9, 2010 at 9:23 PM, Janos Sallai <[email protected]> wrote: > We don't have to worry about platform specific word alignment > peculiarities as long as we stick to nx_structs and nx_unions. The > cc2420x stack I wrote using rfxlink works on the both the msp430 and > the atmega128 with the same message_t definition.
Good to know. > Regarding Packet.clear(): would it make sense for the new message_t to > have a dirty flag in message_t which wouldn't allow the message buffer > to be reused without calling Packet.clear() first? Sure, checking it > would have a runtime overhead, but we could just have a define to turn > that off for production builds. I think it would make more sense to include a byte describing the type of the packet: cc2420_radio, or tinyos_serial, or ieee154_serial, etc. Each such source have a completely different layout of headers, footers and metadata. When you call Packet.clear(), then this type is set. Also, when you receive a message through one of these communication links, then the packet type is also set. One problem is the bridge between the serial and radio, but then we can still do what we always did: Packet.clear() does not change the payload part of the message, and we can query and set the packet length. Miklos > > Janos > > On Thu, Dec 9, 2010 at 1:57 PM, Stephen Dawson-Haggerty > <[email protected]> wrote: >> On Thu, Dec 9, 2010 at 12:29 AM, Miklos Maroti <[email protected]> >> wrote: >>> Hi Stephen, >>> >>> On Thu, Dec 9, 2010 at 2:17 AM, Stephen Dawson-Haggerty >>> <[email protected]> wrote: >>>> On Thu, Dec 9, 2010 at 1:05 AM, Miklos Maroti <[email protected]> >>>> wrote: >>>>> Hi Stephen, >>>>> >>>>> Ok, I understand that. Then what about updating the retry count ONLY >>>>> if it is nonzero? >>>> >>>> What if we updated it to really be the number of retries, rather than >>>> the number of tries? That would be okay with me, I think, and would >>>> make it all consistent. >>> >>> Morten's former email described the situation as: >>> >>> 0: on retry, leave packet ack intact (can be with or without ack) >>> 1: no retry, enable packet ack >>> 2: one retry, enable packet ack >>> >>> We should make all programs behave the same was if it does not care >>> about packet link. This means, that if the retry count is 0, then we >>> should 1) not disable packet ack, 2) we should not update the retry >>> count. >> >> If the programs want consistency, they need to call Packet.clear() >> before reusing a message buffer, which will set retries to zero -- >> they have always needed to do this independent of packetlink. Just >> worth noting. >> >> Anyways, this describes how it *currently* works? And the only change >> we're discussing is to NOT update the retry field when it was >> initially zero? >> >>> >>> By the way, I think currently the code is actually sets the retry >>> count to the actual send count. So we should change the code as I >>> suggested first. >>> >>>>> Also, as Morten writes it here: >>>>> https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-February/004239.html >>>>> we should CLEAR the ACK flags if the retry count is 0, no? >>>> >>>> I agree with that change. >>> >>> With my previous analysis this change should not be made since it >>> would alter the behavior of programs that do not care about packet >>> link. >>> >>>>> By the way, does the retry count need to be 16-bit? >>>> >>>> I doubt it :), although it would probably be padded out on 16-bit >>>> platforms anyways... >>> >>> No, I think it would not, but I am not sure. If the MCU is padding >>> 8-bit numbers with an extra byte, then that would have very bad >>> consequences in the message_t. Again, I do not know the padding >>> behavior, but I would like to know more about this on the msp430. >> >> The MCU doesn't insert the padding -- the compiler does. Pretty much >> everything is going to be word-aligned on the msp430 which means a >> char will often end up being 16 bytes; the alignments are actually set >> in the .platform file. >> >> Steve >> >>> >>> Best, >>> Miklos >>> >>>> >>>>> >>>>> No more questions :) Best, >>>>> Miklos >>>>> >>>>> On Thu, Dec 9, 2010 at 1:24 AM, Stephen Dawson-Haggerty >>>>> <[email protected]> wrote: >>>>>> As I remember, the reason is so the app can determine how many >>>>>> link-layer retransmissions actually occurred. If we remove it we >>>>>> should provide another way to determine this information since it's >>>>>> important for link estimation. >>>>>> >>>>>> Steve >>>>>> >>>>>> On Thu, Dec 9, 2010 at 12:20 AM, Miklos Maroti >>>>>> <[email protected]> wrote: >>>>>>> Hi Guys, >>>>>>> >>>>>>> Morten and Philipp suspect that there is a bug in the >>>>>>> PacketLinkLayerP, which was adopted from the CC2420 PacketLinkP file. >>>>>>> The problem is that before signalling the sendDone event the code >>>>>>> CHANGES the currently set retry count to the number of times the >>>>>>> packet was actually sent. Read Philipp description below. >>>>>>> >>>>>>> Can someone tell WHY the CC2420 code changes the retry count before >>>>>>> the sendDone event? This has subtle consequences, and I think it >>>>>>> should be removed BOTH from the RFXLINK and CC2420 drivers. >>>>>>> >>>>>>> Best, >>>>>>> Miklos >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Philipp Sommer <[email protected]> >>>>>>> Date: Wed, Dec 8, 2010 at 4:20 PM >>>>>>> Subject: Possible bug in PacketLinkLayerP >>>>>>> To: Miklos Maroti <[email protected]> >>>>>>> >>>>>>> >>>>>>> Hi Miklos, >>>>>>> >>>>>>> I think there is a bug related to acknowledgment request in the packet >>>>>>> link layer: >>>>>>> >>>>>>> The signalDone() method in PacketLinkLayerP sets the number of retries >>>>>>> for each successfully transmitted packet (even when no retransmits >>>>>>> were requested). Therefore, the "maxRetries" field in the metadata is >>>>>>> greater than zero when the message_t buffer is passed back to the >>>>>>> application. When the same buffer is used for the next outgoing >>>>>>> message, PacketLinkLayerP.send() will request an ACK for this packet >>>>>>> (even if it should not) since maxRetries is larger than zero. The >>>>>>> problem is that maxRetries is never cleared (since the application >>>>>>> might not even know that the packet link layer is being used, for >>>>>>> example RadioCountToLeds). >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Philipp >>>>>>> >>>>>>> >>>>>>> tos/lib/rfxlink/layers/PacketLinkLayerP.nc: >>>>>>> ================================= >>>>>>> void signalDone(error_t error) { >>>>>>> message_t* msg = currentSendMsg; >>>>>>> currentSendMsg = NULL; >>>>>>> >>>>>>> // AT: A bit of a hack to be able to keep track of the number of >>>>>>> retries >>>>>>> // printfUART("Signaling done with total retries at 0x%x\n", >>>>>>> totalRetries); >>>>>>> >>>>>>> call DelayTimer.stop(); >>>>>>> call PacketLink.setRetries(msg, totalRetries); >>>>>>> signal Send.sendDone(msg, error); >>>>>>> } >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Tinyos-devel mailing list >>>>>>> [email protected] >>>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> stephen dawson-haggerty >>>>>> http://cs.berkeley.edu/~stevedh >>>>>> uc berkeley wireless and embedded systems lab >>>>>> berkeley, ca 94720 >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> stephen dawson-haggerty >>>> http://cs.berkeley.edu/~stevedh >>>> uc berkeley wireless and embedded systems lab >>>> berkeley, ca 94720 >>>> >>> >> >> >> >> -- >> stephen dawson-haggerty >> http://cs.berkeley.edu/~stevedh >> uc berkeley wireless and embedded systems lab >> berkeley, ca 94720 >> >> _______________________________________________ >> Tinyos-devel mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel >> > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
