* sta_info->fail_avg
@ 2008-09-10 23:59 Johannes Berg
2008-09-11 5:15 ` sta_info->fail_avg Javier Cardona
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2008-09-10 23:59 UTC (permalink / raw)
To: Luis Carlos Cobo; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
Hi Luis,
Can you explain what you're using this for in the mesh code? I can't
figure it out, but I do know that neither ath9k's nor Intel's rate
control algorithms ever set it so it'll always be zero.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sta_info->fail_avg
2008-09-10 23:59 sta_info->fail_avg Johannes Berg
@ 2008-09-11 5:15 ` Javier Cardona
2008-09-11 5:24 ` sta_info->fail_avg Luis R. Rodriguez
2008-09-11 10:54 ` sta_info->fail_avg Johannes Berg
0 siblings, 2 replies; 4+ messages in thread
From: Javier Cardona @ 2008-09-11 5:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis Carlos Cobo, linux-wireless
Johannes,
On Wed, Sep 10, 2008 at 4:59 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Hi Luis,
>
> Can you explain what you're using this for in the mesh code?
It is used to estimate the average retransmissions that will be
required to send a nominal frame over a given peer link.
That's one component of the airtime link metric.
> I do know that neither ath9k's nor Intel's rate
> control algorithms ever set it so it'll always be zero.
In that case transmission failures will not be taken into account and
nodes with that hardware will report a lower (better) link metric than
what they should. In other words, those nodes will attract mesh
traffic, which will provide a strong incentive for the driver
maintainers to set that value correctly :)
Cheers,
Javier
--
Javier Cardona
cozybit Inc.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sta_info->fail_avg
2008-09-11 5:15 ` sta_info->fail_avg Javier Cardona
@ 2008-09-11 5:24 ` Luis R. Rodriguez
2008-09-11 10:54 ` sta_info->fail_avg Johannes Berg
1 sibling, 0 replies; 4+ messages in thread
From: Luis R. Rodriguez @ 2008-09-11 5:24 UTC (permalink / raw)
To: Javier Cardona; +Cc: Johannes Berg, Luis Carlos Cobo, linux-wireless
On Wed, Sep 10, 2008 at 10:15:12PM -0700, Javier Cardona wrote:
> Johannes,
>
> On Wed, Sep 10, 2008 at 4:59 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > Hi Luis,
> >
> > Can you explain what you're using this for in the mesh code?
>
> It is used to estimate the average retransmissions that will be
> required to send a nominal frame over a given peer link.
> That's one component of the airtime link metric.
>
> > I do know that neither ath9k's nor Intel's rate
> > control algorithms ever set it so it'll always be zero.
>
> In that case transmission failures will not be taken into account and
> nodes with that hardware will report a lower (better) link metric than
> what they should. In other words, those nodes will attract mesh
> traffic, which will provide a strong incentive for the driver
> maintainers to set that value correctly :)
Neither of our drivers support Mesh yet though so this is good to know,
once we do add it (or someone does).
Luis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: sta_info->fail_avg
2008-09-11 5:15 ` sta_info->fail_avg Javier Cardona
2008-09-11 5:24 ` sta_info->fail_avg Luis R. Rodriguez
@ 2008-09-11 10:54 ` Johannes Berg
1 sibling, 0 replies; 4+ messages in thread
From: Johannes Berg @ 2008-09-11 10:54 UTC (permalink / raw)
To: Javier Cardona; +Cc: Luis Carlos Cobo, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
Javier,
> It is used to estimate the average retransmissions that will be
> required to send a nominal frame over a given peer link.
> That's one component of the airtime link metric.
Ok.
> > I do know that neither ath9k's nor Intel's rate
> > control algorithms ever set it so it'll always be zero.
>
> In that case transmission failures will not be taken into account and
> nodes with that hardware will report a lower (better) link metric than
> what they should. In other words, those nodes will attract mesh
> traffic, which will provide a strong incentive for the driver
> maintainers to set that value correctly :)
Heh, ok. I've been trying to reduce the amount of stuff the rate control
algorithm needs to do, does this need to be in the rate control
algorithm? It seems that the we simply calculate
pf = spinfo->tx_num_failed * 100 / spinfo->tx_num_xmit;
and
fail_avg = ((pf + (spinfo->last_pf << 3)) / 9);
(in a fixed-point format that has more precision)
and we could do all that in the generic code if we get proper
information from the driver. Anyway, for now I'll leave it as-is.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-09-11 10:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-10 23:59 sta_info->fail_avg Johannes Berg
2008-09-11 5:15 ` sta_info->fail_avg Javier Cardona
2008-09-11 5:24 ` sta_info->fail_avg Luis R. Rodriguez
2008-09-11 10:54 ` sta_info->fail_avg Johannes Berg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).