Re: [Madwifi-devel] Madwifi-devel Digest, Vol 48, Issue 3, Message 1

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Mon, May 31, 2010 at 8:00 PM, Nicolas Barati <nic...@gm...>wrote:

> Hello and sorry for bothering you again.
> Thanks for your reply. I did what you told me about checking retries with
> wireshark and the stats turned to be the same as my printk()s. But my
> problem was this: How accurate these stats are at t= say t0. I mean when I
> get ts->ts_longretry = 25 is it actually 25 OR am I getting some staled
> numbers and the real value of longretry is, for example, 29? Because as I
> observed, also the packets wireshark displays are some seconds older than
> those my printks show!  I get 31 retries in my printks but the WS shows me
> 27. And after a few seconds it reaches to 31.
> And when you say estimation of backoff, You actually made it to guess the
> CW value at a given point of time? And You used just ts->ts_long/shortretry
> or you read some other values directly from some REGS? If the first one
> holds, would you suggest me to count on these stats for my Backoff emulation
> attempt?
> Thank you in advance!
> PS: I sent a mail with the subject: "[Madwifi-devel] ath_tx_processq and
> long_short retry " but Sritej' s reply came under this subject! You may
> receive this mail twice ( and sorry for that)  because the first one, as
> madwifi list informed me, is waiting for moderation approval due to its too
> big size. So I re - send this mail with having cut some irrelevant to my
> problem subjects and texts off. Sorry again!
>
> 2010/5/21 sritej s <sr...@gm...>
>
>> I estimated backoff based on these statistics for my project a year back
>> and I got a reasonable estimate.As Mohammad pointed out ,Wire shark is a
>> good tool to verify the retry count.Just check for the retry field in the
>> MAC header. Short retries are for RTS/CTS .Long retries are for the data
>> packets..
>>
>> Thanks,
>> Sritej
>>
>>
>>
>>> Message: 1
>>> Date: Mon, 17 May 2010 22:29:00 +0300
>>> From: Mohammad Abdelhadi <mo....@gm...>
>>> Subject: Re: [Madwifi-devel] ath_tx_processq and long_short retry
>>> To: Nicolas Barati <nic...@gm...>,
>>>        mad...@li...
>>> Message-ID:
>>>        <AAN...@ma...>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> On Mon, May 17, 2010 at 8:00 PM, Nicolas Barati <
>>> nic...@gm...>wrote:
>>>
>>> > Hello all,
>>> > In my research on madwifi 's  back-off, eventually I got convinced that
>>> > there is no way to see the current contention window 's value. So I
>>> turned
>>> > to something else. I tried to disable backoff and then emulate a
>>> backoff
>>> > scheme of my own  on driver level. I disabled backoff by  adding this:
>>> > qi.tqi_qflags |= HAL_TXQ_BACKOFF_DISABLE;   to ath_txq_setup().
>>> > Now I need a measure based on which my backoff emulation will
>>> > increase/decrease  my_CW. I found in ath_tx_status these variables:
>>> > ast_longretry / ast_shortretry. I saw that these values are incremented
>>> > only in ath_tx_processq() which is called from ath_tx_tasklet() or
>>> > ath_tx_tasklet_q0(123)(). I read here :
>>> http://www.makelinux.net/ldd3/chp-7-sect-5.shtml
>>> > about tasklet function and what I understood is that these functions
>>> are
>>> > some kind of timer/scheduling functions.It sayes: "By scheduling a
>>> tasklet,
>>> > you simply ask for it to be executed at a later time chosen by the
>>> kernel".
>>> > If It is so and these tasklet functions are called just some time in
>>> the
>>> > future (regarding current kernel time)  and the long/shortretry
>>> variables
>>> > are incremented only through ath_tx_processq when they are called, how
>>> > accurate these variavles are in regard of the real state of retries.
>>> Are
>>> > they to be trusted? Would you suggest that I consider these variables
>>> for my
>>> > emulation??? And one more question, is disabling backoff done like how
>>> I
>>> > said I did it above? And is there any way to see if it is indeed shut
>>> and
>>> > not enabled again in some other part of the code or some time during
>>> the run
>>> > time of the driver?
>>> >
>>> > Thank you!
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> >
>>> >
>>> > _______________________________________________
>>> > Madwifi-devel mailing list
>>> > Mad...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>>> >
>>> >
>>> Hi,
>>>
>>>  ath_tx_tasklet() is responsible to update information of each
>>> transmitted
>>> packet, please take a look on
>>> http://mesh.calit2.net/whzhao/madwifi_summary.pdf
>>> <http://mesh.calit2.net/whzhao/madwifi_summary.pdf>
>>>  -  how accurate these variavles are in regard of the real state of
>>> retries. Are they to be trusted? Would you suggest that I consider these
>>> variables for my emulation???
>>>
>>> Well, to test the accuracy of these variables, you can use a Network
>>> Analyzer  like Wireshrk, to see how many times a packet has been
>>> retransmitted,
>>>
>>> I think that (ts->ts_longretry) is responsible ot store the number of
>>> long
>>> reties for each packet, but any way, you can test that and see by your
>>> self.
>>>
>>> Hope this helps.
>>>
>>>
>>> Regards,
>>> --
>>> Mohammad Jaser Abdelhadi
>>>
>>> ----------------------------------------------------------------------------
>>> Communications Engineering-Senior Student
>>> Princess Sumaya University for Technology
>>> Mobile: +962777030924
>>> Email: moh...@ie... \ mo....@gm...
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>>
>>>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Madwifi-devel mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>
>
Hi,

Regarding the issue of the long retry counter:

You said that you got a values of the long retry counter such as 29, 31!
Well, i don't think what are you depending on really reflects the true value
of the long retry counter IMHO. As far as I know, the maximum value that the
long retry counter could reach is 10 or 11, then the packet will be
discarded. Therefore, if you really want to get the correct value of the
long retry counter or src, please see the function:
ath_tx_processq, and you will find:
sr = ts->ts_shortretry;
lr = ts->ts_longretry;

Regarding the issue of the CW:

Well, I don't know any method that could reflects the true value of the
current CW, but if you get a true values of the long retry counter, you can
estimate the value of the CW at that moment for a certain packet using the
following equation:

CW = CWmin * ((2^m)-1)

Where:
CWmin is the minimum contention window, which  is 15.
m is the retry counter.

Hope this helps..

Regards,
-- 
Mohammad