[riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication
alex.aring at gmail.com
Thu Oct 15 14:13:21 CEST 2015
On Thu, Oct 15, 2015 at 01:57:03PM +0200, Andreas Weigel wrote:
> Hi everyone,
> I've recently executed some experiments on the performance of Atmel's
> extended operating mode on the ATmega256RFR2 (which afaik is basically the
> same as the AT82RF2xx transceivers) in multihop collection traffic
> scenarios, with unslotted CSMA/CA. For those, we used our own framework for
> WSNs (CometOS). Result is, that the extended operating mode can severely
> impact performance (in terms of PRR) in the presence of large fragmented
> datagrams sent over 6LoWPAN. However, I expect that there will be an impact
> in any traffic scenario with "enough" traffic to get some node's queue
> filled to some extent (resulting in repeated transmissions towards the same
> Problem is the property of the TX_ARET mode to discard any incoming
> transmissions during the backoff phase of the CSMA mechanism. This leads to
> a large number of lost frames on longer paths (4 hops are enough to produce
> a large number of losses), even with rather high backoff exponents and the
> maximum number of retries. This problem caused me to reimplement our mac
> driver for the ATmega256RFR2 using the basic operating mode.
> As far as I can see, the at86rf2xx driver in the riot repo uses the same
> extended operating mode and therefore will very likely have the very same
> weakness. If the time is available, it would probably be a good idea to
> change the driver to use the basic operating mode or alternatively include a
> note for users explaining the impact of the extended operating mode for said
> traffic scenarios. The frame solely caused by the extended operating mode
> can render results of experiments virtually useless (speaking from my own,
> sad experience ;-/ )
I am not a riot-dev but did you try to turn off CSMA-CA handling?
You can do that and I think all (except at86rf230) supports it by
setting MAX_CSMA_RETRIES to 7 which means no CSMA-CA handling.
I would _not_ use TX_ON mode only, because in this mode the ack
request bit in 802.15.4 MAC will be ignored always and sometimes you
need to the result of tx trac status if ACK was received or not. (like
in possible mlme-ops)
TX_ARET_ON will automatic wait for an ACK if ack request bit is set and
not if it isn't set.
Possible solution (maybe also in linux, because I am do a lot of
802.15.4 linux stuff) would be to insert a no CSMA-CA setting which
performs no CSMA-CA handling, but still supports ack handling stuff then.
I was thinking about that already about something like that (in linux) for
such case, because several transceivers supports for disable CSMA-CA handling.
More information about the devel