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
Quoted 4 lines · Dennis Borgmann
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?
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
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
Quoted 12 lines · John W. Linville
Quoted 5 lines · Dennis Borgmann
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/3/25 Dennis Borgmann <[email protected]>:
Quoted 10 lines
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.
Quoted 9 lines
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)
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
A message that is not in the archive (sent off-list or not yet received): [email protected]
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
Quoted 28 lines · Sam Leffler
Quoted 10 lines · 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.
Quoted 8 lines
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