On 05/07/10 10:11, Helmut Schaa wrote: > Am Donnerstag 06 Mai 2010 schrieb Helmut Schaa: >> Am Donnerstag 06 Mai 2010 schrieb Gertjan van Wingerde: >>> On 05/06/10 12:29, Helmut Schaa wrote: >> >> [...] >> >>>> diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c >>>> index 1056c92..5483fec 100644 >>>> --- a/drivers/net/wireless/rt2x00/rt2x00ht.c >>>> +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c >>>> @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry, >>>> __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags); >>>> if (txrate->flags & IEEE80211_TX_RC_SHORT_GI) >>>> __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags); >>>> + >>>> + txdesc->txop = TXOP_HTTXOP; >>>> } >>> >>> I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time >>> using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP? >> >> From what I saw in the ralink driver IFS_BACKOFF is only used for management frames, IFS_SIFS only >> for subsequent frames in a fragment burst and IFS_HTTXOPS for "normal" data frames. But that's >> just the result of a _quick_ review. So I might be wrong here as well :) >> >> To be honest I don't really know what the device does in case IFS_HTTXOPS is set but that was >> the value we've passed to the driver before ;) (==IFS_BACKOFF on all other ralink chips) and it >> works quite well. I also tried IFS_BACKOFF and I wasn't able to see a difference when using >> legacy (11b & 11g) rates (neither on the device itself nor with a second machine monitoring >> the traffic). > > Ok, after further examination it turns out to be: > > - Management frames are sent with IFS_BACKOFF > - Special case for PsPoll frames also with IFS_BACKOFF > - Data frames are sent with IFS_HTTXOP > - Data frame subsequent fragments are send with IFS_SIFS > - CTS frames (in AP mode) use IFS_SIFS > > So, I guess I resend this patch after some testing with IFS_BACKOFF for > management frames and IFS_HTTXOP for data frames and SIFS for subsequent > fragments. > > John, please don't merge this patch yet. Thanks. Thanks for investigating this further. I think the approach you describe above is the correct approach for this. --- Gertjan. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
