2011-03-25 07:42:34

by Dennis Borgmann

[permalink] [raw]
Subject: Disabling ACKs with ath5k

Hello linux-wireless list!

Is there an interface to disable transmission of ACKs and on the other
hand ignoring unreceived ACKs. It can be done with multicasting, but can
it also be achieved by a setting with non-multicast-traffic? I am using
ath5k.

Kind regards,
Dennis


2011-03-25 13:42:35

by Dennis Borgmann

[permalink] [raw]
Subject: Re: Disabling ACKs with ath5k

Hello John,

the goal would be to have a transmission as fast as possible while
ignoring, if a packet reached its destination or not. I'd like to test
wireless performance regarding transmission time in a dedicated
environment. As far as I can see, backoff might already push the
transmission times up quite a lot and if I'd even add the time of -
worst case - 10 retransmissions, the transmission time of one packet
will grow even more.

It would be second-rank, if the packet reaches its destination. Loss of
some packets is not a problem in my testbed.

So I'd like to disable usage of ACKs in order to be off with the only
problem - backoff. Disabling this would of course be nice, but I fear,
that's far more work that just disabling ACKs.

Dennis

John W. Linville schrieb:
> On Fri, Mar 25, 2011 at 08:42:28AM +0100, Dennis Borgmann wrote:
>
>
>> Is there an interface to disable transmission of ACKs and on the other
>> hand ignoring unreceived ACKs. It can be done with multicasting, but can
>> it also be achieved by a setting with non-multicast-traffic? I am using
>> ath5k.
>>
>
> I'm curious, why do you want to do that?
>
>


2011-03-25 13:20:49

by John W. Linville

[permalink] [raw]
Subject: Re: Disabling ACKs with ath5k

On Fri, Mar 25, 2011 at 08:42:28AM +0100, Dennis Borgmann wrote:

> Is there an interface to disable transmission of ACKs and on the other
> hand ignoring unreceived ACKs. It can be done with multicasting, but can
> it also be achieved by a setting with non-multicast-traffic? I am using
> ath5k.

I'm curious, why do you want to do that?

--
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
[email protected] ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.

2011-03-27 20:40:13

by Dennis Borgmann

[permalink] [raw]
Subject: Re: Disabling ACKs with ath5k

Hello Sam,
hello Nick,

thank you for your hints. Multicasting was an option already before.
With your expert opinion I am now confident, that this idea wasn't that bad.

Anyway, i will have a look at the hints given by Nick.

Thank you for your thoughts. It will help me.

Best regards from Germany,
Dennis

Sam Leffler schrieb:
> On Fri, Mar 25, 2011 at 6:42 AM, Dennis Borgmann <
> [email protected]> wrote:
>
>
>> Hello John,
>>
>> the goal would be to have a transmission as fast as possible while
>> ignoring, if a packet reached its destination or not. I'd like to test
>> wireless performance regarding transmission time in a dedicated
>> environment. As far as I can see, backoff might already push the
>> transmission times up quite a lot and if I'd even add the time of -
>> worst case - 10 retransmissions, the transmission time of one packet
>> will grow even more.
>>
>> It would be second-rank, if the packet reaches its destination. Loss of
>> some packets is not a problem in my testbed.
>>
>> So I'd like to disable usage of ACKs in order to be off with the only
>> problem - backoff. Disabling this would of course be nice, but I fear,
>> that's far more work that just disabling ACKs.
>>
>>
>
> Send multicast frames.
>
> -Sam
>
>


2011-03-25 17:06:41

by Nick Kossifidis

[permalink] [raw]
Subject: Re: Disabling ACKs with ath5k

2011/3/25 Dennis Borgmann <[email protected]>:
> Hello John,
>
> the goal would be to have a transmission as fast as possible while
> ignoring, if a packet reached its destination or not. I'd like to test
> wireless performance regarding transmission time in a dedicated
> environment. As far as I can see, backoff might already push the
> transmission times up quite a lot and if I'd even add the time of -
> worst case - 10 retransmissions, the transmission time of one packet
> will grow even more.
>
> It would be second-rank, if the packet reaches its destination. Loss of
> some packets is not a problem in my testbed.
>
> So I'd like to disable usage of ACKs in order to be off with the only
> problem - backoff. Disabling this would of course be nice, but I fear,
> that's far more work that just disabling ACKs.
>
> Dennis
>

Check out these flags...

AR5K_TXDESC_NOACK (set it on each tx descriptor to disable ACKs for
each frames -we do this for beacons already, check out base.c)

AR5K_TXQ_FLAG_BACKOFF_DISABLE (set it when initializing queues, see
how we handle the rest _TXQ_ flags on base.c)


--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick