[ath9k-devel] NF calibration and software level simulation of packet errors

[ath9k-devel] NF calibration and software level simulation of packet errors

[Federico Tramarin]

Dear all,

I have a couple of questions related to the ath9k drivers.

1) 
I was wondering if it is possible to purposely deactivate the ACK transmission on a per-attempt basis.
Specifically, I would like to simulate packet errors at driver level (i.e. software). I already looked at the methods in mac80211
which discard a packet on the basis of some checks. However, if I understood well, in those cases the ACK frame has already been sent by the NIC.
What I would like to do is to say: I received a packet, but since a ?magic number? tells me to discard this, I?ll drop it without acknowledging its reception (as it never arrived). This will consequently trigger backoff and retransmissions on the other side ;)

Is this possible with ath9k? I cannot find any solution by myself. And the NOACK flag is not an option, since I am testing on rate adaptation techniques, so I need varying speeds and ACKs definitely.

2)
Another issue is with RSSI reading. In particular, I am disturbing the channel with an RF generator (not a node). So noise is endless, even during SIFS.
This should decrease the SNR level at the receiver in a controlled way (this is what I want).
However, I am now interested in collecting the readings of RSSI (or SNR as you prefer) from the driver.
This information is available actually, but what happens is that it gets wrong quite soon since noise floor calibration mechanism happen.
It is triggered more or less periodically, and in particular it is forced after three lost beacons?
This calibrate to the new noise floor level, that?s ok.
However, if just after I power off the noise, it never (some tens of seconds is never if I am looking at micro/milliseconds scale) reset the NF.
Only after a long while (and I am not able to understand the rationale here) it reset the NF and things get working again as expected.
It seems that the bit responsible for this is AR_PHY_AGC_CONTROL_NF (in AR_PHY_AGC_CONTROL).

I have actually forced a periodic calibration, but I don?t know if it is the correct way of doing.
Moreover, I discovered NF calibration takes nearly 20 ms. Can you confirm this? Is there a way to have a quicker behavior?


Thank you so much for any help you could provide me
Best wishes to everyone

Federico

----------------------------




Federico Tramarin,  PhD
National Research Council of Italy, CNR-IEIIT
via Gradenigo 6/B
I-35131 Padova, Italy
federico.tramarin at ieiit.cnr.it <mailto:federico.tramarin@ieiit.cnr.it>
Tel: +39 049 827 7645




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151210/fc414dc6/attachment-0001.htm 

[ath9k-devel] NF calibration and software level simulation of packet errors

[Federico Tramarin]

Dear all,

I have a couple of questions related to the ath9k drivers.

1) 
I was wondering if it is possible to purposely deactivate the ACK transmission on a per-attempt basis.
Specifically, I would like to simulate packet errors at driver level (i.e. software). I already looked at the methods in mac80211
which discard a packet on the basis of some checks. However, if I understood well, in those cases the ACK frame has already been sent by the NIC.
What I would like to do is to say: I received a packet, but since a ?magic number? tells me to discard this, I?ll drop it without acknowledging its reception (as it never arrived). This will consequently trigger backoff and retransmissions on the other side ;)

Is this possible with ath9k? I cannot find any solution by myself. And the NOACK flag is not an option, since I am testing on rate adaptation techniques, so I need varying speeds and ACKs definitely.

2)
Another issue is with RSSI reading. In particular, I am disturbing the channel with an RF generator (not a node). So noise is endless, even during SIFS.
This should decrease the SNR level at the receiver in a controlled way (this is what I want).
However, I am now interested in collecting the readings of RSSI (or SNR as you prefer) from the driver.
This information is available actually, but what happens is that it gets wrong quite soon since noise floor calibration mechanism happen.
It is triggered more or less periodically, and in particular it is forced after three lost beacons?
This calibrate to the new noise floor level, that?s ok.
However, if just after I power off the noise, it never (some tens of seconds is never if I am looking at micro/milliseconds scale) reset the NF.
Only after a long while (and I am not able to understand the rationale here) it reset the NF and things get working again as expected.
It seems that the bit responsible for this is AR_PHY_AGC_CONTROL_NF (in AR_PHY_AGC_CONTROL).

I have actually forced a periodic calibration, but I don?t know if it is the correct way of doing.
Moreover, I discovered NF calibration takes nearly 20 ms. Can you confirm this? Is there a way to have a quicker behavior?



Thank you so much for any help you could provide me
Best wishes to everyone

Federico

----------------------------




Federico Tramarin,  PhD
National Research Council of Italy, CNR-IEIIT
via Gradenigo 6/B
I-35131 Padova, Italy
federico.tramarin at ieiit.cnr.it <mailto:federico.tramarin@ieiit.cnr.it>
Tel: +39 049 827 7645




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151214/c79a4b0f/attachment.htm 

[ath9k-devel] NF calibration and software level simulation of packet errors

[Wojciech Dubowik]

>
> Is this possible with ath9k? I cannot find any solution by myself. And 
> the NOACK flag is not an option, since I am testing on rate adaptation 
> techniques, so I need varying speeds and ACKs definitely.
You could use
REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_ACK_DIS);
to disable or
REG_CLR_BIT(ah, AR_DIAG_SW, AR_DIAG_ACK_DIS);
to enable ACK's on per packet basis. I use it sometimes to verify retries.
>
> I have actually forced a periodic calibration, but I don?t know if it 
> is the correct way of doing.
> Moreover, I discovered NF calibration takes nearly 20 ms. Can you 
> confirm this? Is there a way to have a quicker behavior?
>
It takes  more or less 20ms and it's dependent of numer of silent 
periods and channel bandwidth. If you have constant noise then
driver will adapt to it an set a noise floor to that value. RSSI is will 
be of course wrong on the absolute scale as it's always relative to NF.
Only way I know to speed it up is to calibrate NF on each 
channel/bandwidth/temperature/environment for a specific card and use it 
instead of
measured value. The problem is that CCA is not according to the 
regulations as you don't really care what happens on the channel.

I hope it helps,
Wojtek