Search Linux Wireless

Re: [PATCH 1/3] rt2x00: rt2800: update initial SIFS values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 6, 2010 at 8:38 PM, Helmut Schaa
<helmut.schaa@xxxxxxxxxxxxxx> wrote:
> Am Donnerstag 06 Mai 2010 schrieb Ivo Van Doorn:
>> On Thu, May 6, 2010 at 12:29 PM, Helmut Schaa
>> <helmut.schaa@xxxxxxxxxxxxxx> wrote:
>> > Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
>> > used by the Ralink driver nor specified in 802.11.
>> >
>> > Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
>> > Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
>> > 11g + CTS protected connections. Add a comment to the code why we don't use 10us
>> > for CCK SIFS value.
>> >
>> > The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
>> > Ralink drivers).
>>
>> Just wondering, but we hardcode the SIFS value in the rt2x00.h file.
>> Perhaps we should remove it in there, and no longer pass it from
>> rt2x00lib. That way there can't be any confusion about which drivers
>> uses the sifs field and whcih do not.
>
> Yes, wouldn't be too bad I guess. But all non 2800 drivers use the same sifs
> value, so we could just leave the define in rt2x00.h and remove the sifs value
> from the config_erp calback and use the define in all other places?

Well I would still remove the define in that case. I think some of the
legacy drivers
work with different SIFS values but always accepted the value which we used in
the define. So I would still remove the define, and then each driver
is free to set
the value as used in the legacy drivers.

> Nevertheless, I'm not sure why the rt2800 devices don't like the 10us CCK
> SIFS value (which is defined in 802.11) but I wasn't able to get CTS to self
> working correctly with it set to 10 (the actual data frame was sent out
> way too late after the CTS frame, somtimes with delays >100us). Using the 16us
> also for CCK (as the ralink drivers do) results in perfect CTS & data frame
> timing. Maybe it's a hardware issue and the (ralink) driver just works around
> it?

Yes, I expect it to be case. This kind of odd values are used in the
legacy drivers
for other settings as well.

Ivo
--
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

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux