Hi again,
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
transceiver.
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.
Kind Regards,
Andreas
Am 15.10.2015 um 14:48 schrieb Alexander Aring:
Hi,
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@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
