Disabling ACKs with ath5k

Disabling ACKs with ath5k

[Dennis Borgmann]

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

Re: Disabling ACKs with ath5k

[John W. Linville]

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
linville@tuxdriver.com                  might be all we have.  Be ready.

Re: Disabling ACKs with ath5k

[Dennis Borgmann]

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

Re: Disabling ACKs with ath5k

[Nick Kossifidis]

2011/3/25 Dennis Borgmann <dennis.borgmann@googlemail.com>:
> 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

Re: Disabling ACKs with ath5k

[Dennis Borgmann]

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 <
> dennis.borgmann@googlemail.com> 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
>
>