[riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication
andreas.weigel at tuhh.de
Thu Oct 15 20:08:26 CEST 2015
>> Sorry, this sounds awful. Ack handling in software is a mess because you
>> have very timing ciritcal things there.
It still works and I would not call it a mess. With the software
implementation, you can easily use the specified macAckWaitDuration of
864 us (the same is used by the hardware mechanism) and still have a
reliably working network.
>> CSMA-CA handling is the same like above, in my opinion you can not do
>> this in software.
On most transceiver chips you do not have any options but have to
implement CSMA in software because they simply do not provide any
hardware mechanism for backoff->CCA->backoff again/send -- the only ones
I found that DO have such a mechanism in hardware are Atmel's AT86RF2xx
series (including ATmega128RFA1/256RFR2 series) and some Microchip
> On linux, we don't support it in the MAC implementation and
>> we never will do that, because we can't.
I agree. Neither do I say you should.
I just wanted to point out an performance issue -- which occurs with a
certain configuration and in certain traffic scenarios -- to enable
other people to avoid having the same trouble I had with interpreting
the strongly biased results from a testbed.
Am 15.10.2015 um 14:48 schrieb Alexander Aring:
> On Thu, Oct 15, 2015 at 02:38:29PM +0200, Andreas Weigel wrote:
>> Hi again,
>> indeed this should solve the issue -- I have to admit, that I hadn't
>> considered this possibility for our driver, because I adapted the TinyOS MAC
>> layer (using the basic operating mode) and had everything there already,
>> including a handling of the ACKs in software, which works reasonably well.
> Sorry, this sounds awful. Ack handling in software is a mess because you
> have very timing ciritcal things there. That's why at86rf2xx supports
> the RX_AACK states which do AACK handling -> ACK handling on the
> transceiver side.
>> You will obviously still have to implement the CSMA-CA mechanism then if you
>> need it. Is there already usable (for the at86rf2xx) code available for a
>> CSMA-CA in Riot? Then probably combining it with the existing driver (with
>> deactivated CSMA-CA) would be a good solution.
> CSMA-CA handling is the same like above, in my opinion you can not do
> this in software. Okay you working in a little mcu world and yes you
> maybe can do this by calculate all factors, spi-bus speed, max interrupt
> latency, etc. inside the mcu world. If you don't do that and see if it's
> fit, then don't do that.
> CSMA-CA handling is also done by on transceiver side (no software mac
> implementation required) in TX_ARET mode (except you disable it by
> change csma retries to 7).
> I need to admit, I don't know how RIOT handle timing critical 802.15.4
> mac things. On linux, we don't support it in the MAC implementation and
> we never will do that, because we can't.
> - Alex
> devel mailing list
> devel at riot-os.org
More information about the devel