Accurate RX timestamp reporting is important for proper IBSS merging,
mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF
is recorded is needed to sync with the beacon timestamp field.
Tested with AR9280.
Signed-off-by: Thomas Pedersen <[email protected]>
---
v2:
clarify commit log (Luis)
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index a04028b..d4df98a 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -976,7 +976,7 @@ static int ath9k_rx_skb_preprocess(struct ath_common *common,
rx_status->freq = hw->conf.channel->center_freq;
rx_status->signal = ah->noise + rx_stats->rs_rssi;
rx_status->antenna = rx_stats->rs_antenna;
- rx_status->flag |= RX_FLAG_MACTIME_MPDU;
+ rx_status->flag |= RX_FLAG_MACTIME_END;
if (rx_stats->rs_moreaggr)
rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
--
1.7.10.4
On 19 November 2012 17:22, Adrian Chadd <[email protected]> wrote:
> Just do what Sam did in the FreeBSD TDMA code - calculate the actual
> beginning of the frame by using the TSF, the size of the last frame,
> the rate from the last frame, and call ath_hal_calctxtime() (or the
> linux equivalent, obviously.)
>
> For clarification we should find out what the TSF is for 11n
> aggregates. Or the math is totally wrong.
For reference - only the TSF in the final subframe in an aggregate is
valid. The others aren't.
We'll have to jump through some hoops to calculate the timestamp of
each individual MPDU.
Adrian
On Tue, 2012-11-13 at 10:48 -0800, Thomas Pedersen wrote:
> Accurate RX timestamp reporting is important for proper IBSS merging,
> mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF
> is recorded is needed to sync with the beacon timestamp field.
> - rx_status->flag |= RX_FLAG_MACTIME_MPDU;
> + rx_status->flag |= RX_FLAG_MACTIME_END;
This and the other similar patches obviously won't apply any more.
Before you repost though I think it would make sense to fix the
calculation issue that Simon pointed out on the radiotap list? I hope he
comes up with some code though as I'm not good enough at bitrate
calculations :-)
johannes
Accurate RX timestamp reporting is important for proper IBSS merging,
mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF
is recorded is needed to sync with the beacon timestamp field.
Tested with AR9271.
Signed-off-by: Thomas Pedersen <[email protected]>
---
v2:
clarify commit log (Luis)
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 06cdcb7..1708b01 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -1082,7 +1082,7 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv *priv,
rx_status->freq = hw->conf.channel->center_freq;
rx_status->signal = rxbuf->rxstatus.rs_rssi + ATH_DEFAULT_NOISE_FLOOR;
rx_status->antenna = rxbuf->rxstatus.rs_antenna;
- rx_status->flag |= RX_FLAG_MACTIME_MPDU;
+ rx_status->flag |= RX_FLAG_MACTIME_END;
return true;
--
1.7.10.4
Just do what Sam did in the FreeBSD TDMA code - calculate the actual
beginning of the frame by using the TSF, the size of the last frame,
the rate from the last frame, and call ath_hal_calctxtime() (or the
linux equivalent, obviously.)
For clarification we should find out what the TSF is for 11n
aggregates. Or the math is totally wrong.
Thanks,
Adrian
On 19 November 2012 13:39, Johannes Berg <[email protected]> wrote:
> Before you repost though I think it would make sense to fix the
> calculation issue that Simon pointed out on the radiotap list? I hope he
> comes up with some code though as I'm not good enough at bitrate
> calculations :-)
What was his comment?
Adrian
On Mon, Nov 19, 2012 at 2:32 PM, Adrian Chadd <[email protected]> wrote:
> On 19 November 2012 13:39, Johannes Berg <[email protected]> wrote:
>
>> Before you repost though I think it would make sense to fix the
>> calculation issue that Simon pointed out on the radiotap list? I hope he
>> comes up with some code though as I'm not good enough at bitrate
>> calculations :-)
>
> What was his comment?
Since it's not on gmane yet:
"Unfortunately this patch does not do a very accurate calculation, so
it makes the problem worse. It simply multiplies rate by the number of
bits to get a time. This does not take into account the limited
accuracy in rate (11n has fractional rates), nor does it consider the
rounding into blocks caused by FEC, or symbols. As a result the data
is made worse by the current code. Either the code should do an
accurate fix, or it should record the raw value and let the end user
correct it properly."
---
Thomas