Hi Andreas, hi Alexander,
I'm implementing a new MAC layer [1] for RIOT at the moment. It's
inspired by TinyOS LPL and ContikiMAC, but not compatible (at least not
yet). I'm developing against our at86rf2xx driver as a reference. You
can use it afaict the same as if it were using Basic Mode by disabling
NETOPT_AUTOACK, so no need to rewrite the driver. Concerning CSMA you
can also easily disable CSMA/CA via NETOPT_CSMA if you wish.
I also kind of implemented my own ACKs (called wakeup request - WR) that
will be sent with CSMA/CA enabled, but without automatic resending
(CSMA_RETRIES = 0). On the other hand I send the payload using AUTOACK
so that I can tell if it really arrived at the destination. I couldn't
test it on a bigger testbed yet, let alone multi-hop, but I can not yet
imagine that performance would suffer that much. Still have to read your
article though.
Cheers,
Daniel
[1] https://github.com/RIOT-OS/RIOT/pull/3730
Am 15.10.2015 um 14:38 schrieb Andreas Weigel:
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.
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.
Regards,
Andreas
On 10/15/2015 02:13 PM, Alexander Aring wrote:
Hi,
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
node).
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.
- Alex
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
