Dear rebasing IOTlers,
this question goes mostly to people working on MAC protocols and those who are
working on non-GNRC network stacks: is there any branch I can use to count the
number of retransmissions on the link layer? With the default at86rf2xx driver
and GNRC's nomac, the driver takes care about link layer retransmissions
automatically without any possibility to access the actual numbers. I took a
brief look in https://github.com/RIOT-OS/RIOT/pull/3730 and
https://github.com/RIOT-OS/RIOT/pull/4184, but couldn't determine if they are
not also using (at least partly) the extended operation mode of the device for
link-layer auto-acks.
Or does lwip or emb6 provides its own MAC layer implementation by any chance?
Cheers,
Oleg
Hi Oleg,
speaking for my PR (3730), I don’t use automatic retransmission except for the final payload packet, given that the packets that negotiate a connection don’t use Link-Layer ACKs. I don’t change the number of retries.
However, if you are interested in the retransmission count for the default stack (i.e. at86rf2xx + nomac), you can find the count for the current transmission in regsiter XAH_CTRL_2 of the transceiver. But to my knowledge, this isn’t implemented yet.
For which metric are you interested in link-layer retransmissions?
Cheers,
Daniel
Hi Daniel!
Thanks for your timely reply!
However, if you are interested in the retransmission count for the default
stack (i.e. at86rf2xx + nomac), you can find the count for the current
transmission in regsiter XAH_CTRL_2 of the transceiver. But to my knowledge,
this isn't implemented yet.
Ah, thanks for the pointer. Unfortunately, this register is only available on
the AT86RF233, but not on the AT86RF231. Since I'm performing my experiments
on the IoT-LAB testbed and the nodes there are equipped with the AT86RF231,
I'm doomed here.
For which metric are you interested in link-layer retransmissions?
I'm running some experiments where I tune parameters on the upper layers as
well as on the link-layer and want to evaluate how many packets were actually
required in different settings to retrieve data in a multi-hop scenario.
Cheers,
Oleg
Hi Oleg,
I’m running some experiments where I tune parameters on the upper layers as well as on the link-layer and want to evaluate how many packets were actually required in different settings to retrieve data in a multi-hop scenario.
The only thing that comes to my mind would be measuring the time inside the driver for AT86RF231. Since you know the frame length and transmission times are deterministic, you should be able to deduct the number of retransmissions. But CSMA then might be a problem, because it introduces random delays 
Cheers,
Daniel
Hi,
if there is no code available, wouldn't it be rather easy to introduce a simple intermediate layer, set the number of retransmissions in the driver to 0, and re-initiate the transmission every time the driver reports a failure (up to the desired number of retransmissions) and count the retransmissions there? You probably loose some microseconds compared to the hardware solution, but gain the information you need.
Regards,
Andreas
PS: As you are speaking of multi-hop traffic, I'd like to use the opportunity to bring attention to the "deafness"-problem again, which may impact performance using the extended operating mode in combination with multi-hop traffic. (mailing list topic: at86rf2xx radio driver -- potential severe performance issues for multi-hop communication)
Hi Andreas!
if there is no code available, wouldn't it be rather easy to introduce a
simple intermediate layer, set the number of retransmissions in the driver
to 0, and re-initiate the transmission every time the driver reports a
failure (up to the desired number of retransmissions) and count the
retransmissions there? You probably loose some microseconds compared to the
hardware solution, but gain the information you need.
Yes, that's indeed the solution we discussed some time ago. Unfortunately,
it's a bit more complicated than that since the transceiver would not pass
link-layer ACKs up to software in extended mode and in basic mode the driver
has to perform the address checks in software, too. So, all in all, it is
doable, but requires some work and it's not 100% clear how much overhead it
actually generates.
However, Thomas Eichinger is already working on that and has completed the
driver rework. (Thanks for that!) Hence, I was checking if the link-layer
part (handling ACKs and taking care of retransmissions) might be already
available in some other pieces of code.
PS: As you are speaking of multi-hop traffic, I'd like to use the
opportunity to bring attention to the "deafness"-problem again, which may
impact performance using the extended operating mode in combination with
multi-hop traffic. (mailing list topic: at86rf2xx radio driver -- potential
severe performance issues for multi-hop communication)
Thanks for the reminder. So far I didn't experienced any severe performance
problems, but maybe I should take a closer look.
Cheers,
Oleg
Hi Oleg,
probably there is a misunderstanding (I'm also not quite 100% sure at which end 
)
would not pass link-layer ACKs up to software in extended mode
Hence, I was checking if the link-layer
part (handling ACKs and taking care of retransmissions) might be already
available in some other pieces of code.
My suggestion would still use the extended operating mode, with automatic ACKS and retransmissions activated (and backoff, cca, address filtering) and it would therefore also handle the waiting/timeout for ACKs. Thus there is no need to pass those anywhere. It would just do so with retransmissions disabled (at86rf2xx_set_max_retries()) and thereby providing an opportunity to count the number of transmissions within an intermediate layer, i.e., (pseudo-code):
handleTxEnd() {
if result == success:
pass result success and numRetransmissions to upper layer
else:
if numRetransmissions < numMaxRetransmissions:
numRetransmissions++
pass frame to radio driver again
else:
pass result failure to upper layer
}
Therefore I tend to disagree with
it's a bit more complicated than that
Am I overlooking/misunderstanding something?
Regards,
Andreas