* [ath9k-devel] SoftMAC link layer acks generation in software
@ 2013-12-18 2:18 Shinnazar
0 siblings, 0 replies; 4+ messages in thread
From: Shinnazar @ 2013-12-18 2:18 UTC (permalink / raw)
To: ath9k-devel
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131218/6582a3ba/attachment.htm
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ath9k-devel] SoftMAC link layer acks generation in software
@ 2014-01-30 16:47 Alessandro CIOFANI
0 siblings, 0 replies; 4+ messages in thread
From: Alessandro CIOFANI @ 2014-01-30 16:47 UTC (permalink / raw)
To: ath9k-devel
Hello everybody!
Just a report after a period of testing...
Unfortunately we were not able to solve the problem, still too slow ack for
a station to "believe" it is an ack for a successfully received frame.
The ack is received at 250-350 usecs after a frame reception (measured at a
mitm monitor station with wireshark).
Steps done since last mail:
set general properties
file hw.c, function ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel
*chan, struct ath9k_hw_cal_data *caldata, bool fastcc)
REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_ACK_DIS);
REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH);
REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_IGNORE_VIRT_CS);
REG_SET_BIT(ah, AR_D_GBL_IFS_MISC, AR_D_GBL_IFS_MISC_IGNORE_BACKOFF);
set queue properties:
hard coded at the end of ath9k_hw_set_txq_props function, in mac.c
qi=&ah->txq[4];
qi->tqi_aifs=0;
qi->tqi_cwmin=0;
qi->tqi_cwmax=0;
qi->tqi_qflags |= TXQ_FLAG_BACKOFF_DISABLE;
in main.c, created a generic socket buffer ack, in ath9k_start function
//----------------------------er2k
ackskb = dev_alloc_skb(1500);
skb_reserve(ackskb, 500);
//now has head and tail but no data space
ackskb->data = skb_put(ackskb, 500);
//now we have an skb with 500 head, 500 data sec, 500 tail
//------------------------------------skb
// Set skb->cb with tx_info
//
//------------------------------------
memset(ackskb->cb, 0, sizeof(ackskb->cb));
info = IEEE80211_SKB_CB(ackskb);
/* don't expect acks addressed to us */
info->flags |= IEEE80211_TX_CTL_NO_ACK;
/* XXX: internal to mac80211 and can be ignored */
info->flags |= IEEE80211_TX_CTL_INJECTED;
info->control.vif = NULL;
info->control.rates[0].count = 1;
for (i = 1; i < IEEE80211_TX_MAX_RATES; i++)
info->control.rates[i].idx = -1;
//-------------------------------------------------
//
// set header
//
//----------------------------------------------------
memset(ackskb->data, 0, 500);
skb_set_mac_header(ackskb, 0);
skb_set_network_header(ackskb, 0);
skb_set_transport_header(ackskb, 0);
hdr11 = (struct ieee80211_hdr *) ackskb->data;
hdr11->frame_control |= cpu_to_le16(IEEE80211_FTYPE_CTL);
hdr11->frame_control |= cpu_to_le16(IEEE80211_STYPE_ACK);
hdr11->duration_id = cpu_to_le16(62);
//--------------------------------------------------------
//
// Other sk_buff stuff
//
//--------------------------------------------------------
ackskb->ip_summed = CHECKSUM_UNNECESSARY;
ackskb->pkt_type = PACKET_OTHERHOST;
ackskb->protocol = htons(ETH_P_802_2);
// ackskb->priority = cpu_to_le32(7);
ackskb->queue_mapping = 4;
ackskb->len = 10;
in recv.c (function ath_rx_tasklet) a function has been added to copy
the original skbuff created to prepare an ack frame, modify destination mac
address and pass it to ath9k_ops.tx() funcion:
int ath9k_rx_tobeack(struct ieee80211_local *local, struct sk_buff
*origskb,struct ieee80211_hdr *hdr)
{
extern struct ieee80211_ops ath9k_ops;
extern struct sk_buff *ackskb;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(origskb);
struct ieee80211_hdr *hdr11;
struct ieee80211_tx_info *info;
struct ieee80211_channel *channel;
struct ieee80211_tx_control *txcontrol;
struct ieee80211_sta *stap;
int rate_idx;
__le16 framecontrol;
struct sta_info *sta;
int i;
struct sk_buff *skb;
framecontrol |= cpu_to_le16(IEEE80211_STYPE_ACK);
framecontrol |= cpu_to_le16(IEEE80211_FTYPE_CTL);
channel = local->hw.conf.chandef.chan;
if ( ieee80211_is_ctl(hdr->frame_control)
|| ieee80211_is_beacon(hdr->frame_control)
|| is_broadcast_ether_addr(hdr->addr1)
|| is_multicast_ether_addr(hdr->addr1)
|| ieee80211_is_ack(hdr->frame_control)
|| ieee80211_is_mgmt(hdr->frame_control)) {
return -1;
}
if (ieee80211_is_data_present(hdr->frame_control)
|| ieee80211_is_qos_nullfunc(hdr->frame_control) ||
ieee80211_is_nullfunc(hdr->frame_control) ) {
skb= skb_copy(ackskb, GFP_ATOMIC);
if (skb == NULL)
return -1;
info = IEEE80211_SKB_CB(skb);
info->flags |= IEEE80211_TX_CTL_INJECTED;
channel = local->hw.conf.chandef.chan;
info->band = channel->band;
info->rate_driver_data[0]=channel;
info->control.rates[0].idx = rate_idx;
info->control.vif = NULL;
info->control.rates[0].count = 1;
txcontrol = kcalloc(1, sizeof(struct ieee80211_tx_control), GFP_ATOMIC);
hdr11 = (struct ieee80211_hdr *) skb->data;
hdr11->duration_id = cpu_to_le16(0);
memcpy(hdr11->addr1,hdr->addr2 , ETH_ALEN);
skb->dev = origskb->dev;
ath9k_ops.tx(local, txcontrol, skb);
kfree(txcontrol);
return 0;
}
return -1;
}
Acks still are too slow so further analysis is required.
Where are we losing time?
1. In receiving the frame (time passed between radio receiving the frame
and time we enter in rx tasklet)?
2. Or in preparing the ack to be transmitted?
3. Or in the radio waiting too much time before sending the frame over the
air?
Try to solve...
1. Measuring the difference between timestamp in skbuf coming from radio
card and a locally generated one in rx tasklet, it seems, more or less,
that it takes a maximum of 5 microseconds for a frame successfully received
to arrive in the driver (measuring technique a little weird, hope it is
correct enough...).
2. To measure the time it takes for ack to prepared and queued, we measure
the difference between 2 timestamps set at the beginning and at the end of
the entire process, right at the end of the ath9k_ops.tx and kfree
functions.
recv.c file, function: ath_rx_tasklet:
cycle beginning - time arrival timestamp computation:
unsigned long time_in_micros, time_in_micros2;
struct timeval te, tv;
do_gettimeofday(&tv);
time_in_micros = 1000000 * tv.tv_sec + tv.tv_usec;
then we call ack sending function and compute the time again to print the
difference:
if (!ath9k_rx_tobeack(local, skb,hdr)) {
do_gettimeofday(&te);
time_in_micros2 = 1000000 * te.tv_sec + te.tv_usec;
printk("Er2k acked %u usecs \n",(unsigned int) (time_in_micros2 -
time_in_micros));
}
This is the result, from the frame receiving to the ack queuing time we
get an average of 12 microseconds
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.508219] Er2k acked 12
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.648176] Er2k acked 27
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.657947] Er2k acked 18
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.667250] Er2k acked 11
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.676417] Er2k acked 11
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.685699] Er2k acked 11
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.694877] Er2k acked 10
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.704176] Er2k acked 11
usecs
Wed Jan 15 14:54:26 2014 auth.err kernel: [ 113.713367] Er2k acked 11
usecs
So it seems, as you suggested, we must concentrate in managing card
behavior (backoff, careier sense, etc.).
What do you think about the whole process?
Suggestions?
We're a little stuck right now...
Thankz!!!
2013-12-18 Pradeep Reddy <pradeepreddy.iit@gmail.com>
> Hi Alex,
>
> Along with other register settings to disable backoff, set the Tx queue
> properties to disable the backoff. The register bit that needs to be set is
> AR_D_MISC_POST_FR_BKOFF_DIS
>
> ref:
> REG_SET_BIT(ah, AR_DMISC(*qnum*), AR_D_MISC_POST_FR_BKOFF_DIS);
>
> You need to replace the qnum with Tx Queue number, which is 7 in your case.
>
> Regards
> Pradeep
>
--
++++++++++++++++++++++++++++++++++++
Alessandro CIOFANI
ERGON 2000
Via Collazia, 4/C - 00183 - ROMA
Tel.:+39 06.622.79.622 - Fax: +39 06.622.98.498
alex at ergon2000.it
++++++++++++++++++++++++++++++++++++
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140130/24d95382/attachment.htm
^ permalink raw reply [flat|nested] 4+ messages in thread* [ath9k-devel] SoftMAC link layer acks generation in software
@ 2013-12-18 11:54 Pradeep Reddy
0 siblings, 0 replies; 4+ messages in thread
From: Pradeep Reddy @ 2013-12-18 11:54 UTC (permalink / raw)
To: ath9k-devel
Hi Alex,
Along with other register settings to disable backoff, set the Tx queue
properties to disable the backoff. The register bit that needs to be set
is AR_D_MISC_POST_FR_BKOFF_DIS
ref:
REG_SET_BIT(ah, AR_DMISC(*qnum*), AR_D_MISC_POST_FR_BKOFF_DIS);
You need to replace the qnum with Tx Queue number, which is 7 in your case.
Regards
Pradeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131218/375af5f0/attachment.htm
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ath9k-devel] SoftMAC link layer acks generation in software
@ 2013-12-17 14:30 Alessandro CIOFANI
0 siblings, 0 replies; 4+ messages in thread
From: Alessandro CIOFANI @ 2013-12-17 14:30 UTC (permalink / raw)
To: ath9k-devel
Hello everybody!
I's my first time writing to the list, while I'm following it with interest
for some time.
We're developing some MAC functions in software for testing purposes.
The most challenging part seems to be generating Acks in software.
Three main tasks:
1. Disabling Link Layer Acks in hardware
2. Generating Acks as "low" as possible in driver stack
3. sending such acks as quickly as possible
Now, task 1 and 2 are done in ath9k: task 1 setting the appropriate flag in
the register and task 2 coding link layer ack generation in ath9k_rx
tasklet.
We have a problem in task 3.
It seems that the ack frame is sent like regular frames, respecting CCA,
while we would need the ack frames to be sent immediately, as soon as
they've been put in the tx queue.
Test environment
Access Point
Hardware: Alix 2d2 board, Compex WLM200NX MiniPCI network adapter (should
be Chipset AR9220 according to vendor datasheet - kernel Dmesg says
"ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xd0ca0000, irq=9")
Software: OpenWRT REVISION r37112
Client
any WiFi compliant client such as smartphones and laptop
Sniffer
wireshark on a laptop with a mon interface
Results
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-30 16:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-18 2:18 [ath9k-devel] SoftMAC link layer acks generation in software Shinnazar
-- strict thread matches above, loose matches on Subject: below --
2014-01-30 16:47 Alessandro CIOFANI
2013-12-18 11:54 Pradeep Reddy
2013-12-17 14:30 Alessandro CIOFANI
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.