Johannes
How did you planed to get transmission rate back to scaling algorithm
through tx_status?
I'm finding it a bit cumbersome,. now when tx_rate is pointer and
doesn't resides in the ieee80211_tx_control
I've seen in your patch you've just ripped this code off but our rate
scale algorithms doesn't work without it actually the code that read
this value in rate scale algorithm is there but it actually looking
into empty space...
- tx_status->control.tx_rate =
- iwl4965_hw_get_rate_n_flags(tx_resp->rate_n_flags);
I'm just asking if you had something in mind or it's just something you forgot.
struct ieee80211_tx_control {
struct ieee80211_vif *vif;
struct ieee80211_rate *tx_rate; ---here
}
Thanks
Tomas
On Feb 4, 2008 8:20 PM, Kalle Valo <[email protected]> wrote:
> Sam Leffler <[email protected]> writes:
>
> >>> I see. Rate scale algorithm only tels FW from what rate to start
> >>> transmission. FW is responsible to do downscaling. Which is quite
> >>> reasonable as retransmission is real time process. Instead of
> >>> retransmitting on the same rate FW downscales. T X response provides
> >>> to the rate scaling algorithm the successful rate.
> >>
> >> I just want to point out this is an important feature when the bus is
> >> very slow, for example SPI bus in embedded devices. Retransfering
> >> frames through SPI for every rate restransmit would make such a device
> >> extremely slow.
> >
> > I don't know of a part that does repeated DMA to implement retransmit;
> > do you have an example?
>
> Asking me? No, I have never heard of such a device.
>
Actually what is probably happening with some devices, I'm not sure
though, they retries in FW/HW but do not downscale.
Tomas
> Kalle Valo
>
Sam Leffler <[email protected]> writes:
>>> I see. Rate scale algorithm only tels FW from what rate to start
>>> transmission. FW is responsible to do downscaling. Which is quite
>>> reasonable as retransmission is real time process. Instead of
>>> retransmitting on the same rate FW downscales. T X response provides
>>> to the rate scaling algorithm the successful rate.
>>
>> I just want to point out this is an important feature when the bus is
>> very slow, for example SPI bus in embedded devices. Retransfering
>> frames through SPI for every rate restransmit would make such a device
>> extremely slow.
>
> I don't know of a part that does repeated DMA to implement retransmit;
> do you have an example?
Asking me? No, I have never heard of such a device.
--
Kalle Valo
> I'm finding it a bit cumbersome,. now when tx_rate is pointer and
> doesn't resides in the ieee80211_tx_control
> I've seen in your patch you've just ripped this code off but our rate
> scale algorithms doesn't work without it actually the code that read
> this value in rate scale algorithm is there but it actually looking
> into empty space...
>
> - tx_status->control.tx_rate =
> - iwl4965_hw_get_rate_n_flags(tx_resp->rate_n_flags);
>
> I'm just asking if you had something in mind or it's just something you forgot.
TBH, that confused me completely since the rate scale algorithm tells
the hardware what rate to use so why does the hw need to assign a
different rate in the tx status?
johannes
On Feb 3, 2008 4:37 PM, Johannes Berg <[email protected]> wrote:
>
> > I'm finding it a bit cumbersome,. now when tx_rate is pointer and
> > doesn't resides in the ieee80211_tx_control
> > I've seen in your patch you've just ripped this code off but our rate
> > scale algorithms doesn't work without it actually the code that read
> > this value in rate scale algorithm is there but it actually looking
> > into empty space...
> >
> > - tx_status->control.tx_rate =
> > - iwl4965_hw_get_rate_n_flags(tx_resp->rate_n_flags);
> >
> > I'm just asking if you had something in mind or it's just something you forgot.
>
> TBH, that confused me completely since the rate scale algorithm tells
> the hardware what rate to use so why does the hw need to assign a
> different rate in the tx status?
I see. Rate scale algorithm only tels FW from what rate to start
transmission. FW is responsible to do downscaling. Which is quite
reasonable as retransmission is real time process. Instead of
retransmitting on the same rate FW downscales. T X response provides
to the rate scaling algorithm the successful rate.
There is a little difference between 4956 and 3945 how the rate scale
table is given to FW, but this is off the topic.
Thanks
Tomas
> johannes
>
Kalle Valo wrote:
> Tomas Winkler <[email protected]> writes:
>
>
>>> TBH, that confused me completely since the rate scale algorithm tells
>>> the hardware what rate to use so why does the hw need to assign a
>>> different rate in the tx status?
>>>
>> I see. Rate scale algorithm only tels FW from what rate to start
>> transmission. FW is responsible to do downscaling. Which is quite
>> reasonable as retransmission is real time process. Instead of
>> retransmitting on the same rate FW downscales. T X response provides
>> to the rate scaling algorithm the successful rate.
>>
>
> I just want to point out this is an important feature when the bus is
> very slow, for example SPI bus in embedded devices. Retransfering
> frames through SPI for every rate restransmit would make such a device
> extremely slow.
>
I don't know of a part that does repeated DMA to implement retransmit;
do you have an example?
Regardless, the original issue is independent; good devices support
multi-rate retransmit so the final tx rate may not be the same as the
rate specified for the initial series. Whether this is done in fw or hw
doesn't matter.
Sam
Tomas Winkler <[email protected]> writes:
>> TBH, that confused me completely since the rate scale algorithm tells
>> the hardware what rate to use so why does the hw need to assign a
>> different rate in the tx status?
>
> I see. Rate scale algorithm only tels FW from what rate to start
> transmission. FW is responsible to do downscaling. Which is quite
> reasonable as retransmission is real time process. Instead of
> retransmitting on the same rate FW downscales. T X response provides
> to the rate scaling algorithm the successful rate.
I just want to point out this is an important feature when the bus is
very slow, for example SPI bus in embedded devices. Retransfering
frames through SPI for every rate restransmit would make such a device
extremely slow.
--
Kalle Valo