On 2010-06-28 12:20 PM, Björn Smedman wrote:
> 2010/6/28 Felix Fietkau :
>> On 2010-06-28 2:01 AM, Björn Smedman wrote:
> [snip]
>>> I guess the real solution is your rewrite... But in the mean time
>>> perhaps we can memcpy the tx_info control from the last subframe to
>>> the first before calling
2010/6/28 Felix Fietkau :
> On 2010-06-28 2:01 AM, Björn Smedman wrote:
[snip]
>> I guess the real solution is your rewrite... But in the mean time
>> perhaps we can memcpy the tx_info control from the last subframe to
>> the first before calling ath_buf_set_rate() in ath_tx_sched_aggr()?
>> Could
On 2010-06-28 2:01 AM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau :
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
>>> [snip] As
>>> far as I can tell, whenever the first subframe of an aggregate fails
>>> and is software retried, the rate control feedback for that aggregate
>>> is lost (ath_tx
2010/6/23 Felix Fietkau :
> On 2010-06-23 6:36 PM, Björn Smedman wrote:
>> [snip] As
>> far as I can tell, whenever the first subframe of an aggregate fails
>> and is software retried, the rate control feedback for that aggregate
>> is lost (ath_tx_rc_status() is never called with update_rc = true
2010/6/23 Felix Fietkau :
> On 2010-06-23 8:47 PM, Björn Smedman wrote:
[snip]
>> But on the other hand doesn't that also mean that MRR rates and counts
>> in the tx status will be incorrect? I.e. one set of rates/counts used
>> to transmit the aggregate (first subframe) and (possibly) another set
On 2010-06-23 8:47 PM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau :
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
> [snip]
>>> If I'm not wrong above then the rate control feedback must also be
>>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>>> the rate control algori
2010/6/23 Felix Fietkau :
> On 2010-06-23 6:36 PM, Björn Smedman wrote:
[snip]
>> If I'm not wrong above then the rate control feedback must also be
>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>> the rate control algorithm through the thin tx status interface. As
>> far
On 2010-06-23 6:36 PM, Björn Smedman wrote:
> 2010/3/2 Felix Fietkau :
>> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>>> 2010/3/2 Felix Fietkau :
> [snip]
>>> You mean the hardware interprets the block-ack and keeps retrying the
>>> un-acked frames? I thought it stopped as soon as it got a block-a
2010/3/2 Felix Fietkau :
> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>> 2010/3/2 Felix Fietkau :
[snip]
>> You mean the hardware interprets the block-ack and keeps retrying the
>> un-acked frames? I thought it stopped as soon as it got a block-ack to
>> let software sort out the acked and un-acke
