mesh questions/suggestion about airtime metric and device constant in mesh_hwmp.c

mesh questions/suggestion about airtime metric and device constant in mesh_hwmp.c

[Jean-Pierre Tosoni]

Hi all,

The airtime_link_metric_get()  function follows closely section 13.9 of the
standard, except for the "channel access overhead" which is said to depend
on the PHY, headers, etc. 
Hence I understand that a complete implementation is not trivial.

The 'device_constant' variable is given the constant value '1<<ARITH_SHIFT',
which means 1 microsecond if I am correct. But the smallest possible
duration for the PPDU header is 20 microseconds in non-HT or 24 us in HT, as
shown in section 20.3.2

For the test frame of 8192 bits, say at 300Mbps (MCS15), Bt/r = the
currently computed airtime is 28 instead of 51, underevaluated by -45% !
Since the value accumulates on the mesh path, it may make a big difference
for the path selection.

Questions:
Even if device_constant is kept as a constant, shouldn't we set it to
something more realistic, like 20 or 24 ?
(I mean 20<<ARITH_SHIFT)
Does the standard really mean to include the PPDU header ?

(By the way, I understand that this value should also include the DIFS, and
maybe the ACK, so it should be much greater than 20)

Regards,

Jean-Pierre Tosoni

Re: mesh questions/suggestion about airtime metric and device constant in mesh_hwmp.c

[Thomas Pedersen]

+ o11s-devel

On Mon, Apr 15, 2013 at 3:39 PM, Jean-Pierre Tosoni <jp.tosoni@acksys.fr> wrote:
> Hi all,
>
> The airtime_link_metric_get()  function follows closely section 13.9 of the
> standard, except for the "channel access overhead" which is said to depend
> on the PHY, headers, etc.
> Hence I understand that a complete implementation is not trivial.
>
> The 'device_constant' variable is given the constant value '1<<ARITH_SHIFT',
> which means 1 microsecond if I am correct. But the smallest possible

The airtime is in units of 0.01TU, so a device_constant of 1 is more like 10us.

> duration for the PPDU header is 20 microseconds in non-HT or 24 us in HT, as
> shown in section 20.3.2
>
> For the test frame of 8192 bits, say at 300Mbps (MCS15), Bt/r = the
> currently computed airtime is 28 instead of 51, underevaluated by -45% !
> Since the value accumulates on the mesh path, it may make a big difference
> for the path selection.

Since O (channel access overhead) is constant, changing it just scales
the metric equally across all links, so I'm not sure what difference
this would make?

Getting device_constant as a function of current protection parameters
and channel type (ie. actual channel access overhead) however, makes
sense.

> Questions:
> Even if device_constant is kept as a constant, shouldn't we set it to
> something more realistic, like 20 or 24 ?
> (I mean 20<<ARITH_SHIFT)
> Does the standard really mean to include the PPDU header ?
>
> (By the way, I understand that this value should also include the DIFS, and
> maybe the ACK, so it should be much greater than 20)

-- 
Thomas

RE: mesh questions/suggestion about airtime metric and device constant in mesh_hwmp.c

[Jean-Pierre Tosoni]

Hi Thomas,

> -----Message d'origine-----
> De : Thomas Pedersen [mailto:thomas@cozybit.com]
> Envoyé : mardi 16 avril 2013 14:26
> On Mon, Apr 15, 2013 at 3:39 PM, Jean-Pierre Tosoni
> <jp.tosoni@acksys.fr> wrote:
> >
> > The 'device_constant' variable is given the constant value
> > '1<<ARITH_SHIFT', which means 1 microsecond if I am correct. 
> 
> The airtime is in units of 0.01TU, so a device_constant of 1 is more like
> 10us.

Then the code is wrong, because the airtime is never converted to 0.01TU ?
The comment says 'units of 100kbps' (which is true, I checked in
cfg80211_calculate_bitrate()), after that the code applies a 10 factor to
convert to units of 1Mbps, so the unit of tx_time is 1us, so device_constant
is in us as well.

> 
> > duration for the PPDU header is 20 microseconds in non-HT or 24 us in
> > HT, as shown in section 20.3.2
> >
> > For the test frame of 8192 bits, say at 300Mbps (MCS15), Bt/r = the
> > currently computed airtime is 28 instead of 51, underevaluated by -45% !
> > Since the value accumulates on the mesh path, it may make a big
> > difference for the path selection.
> 
> Since O (channel access overhead) is constant, changing it just scales
> the metric equally across all links, so I'm not sure what difference
> this would make?

Two reasons:

1) If we want a path from A to C, and there are two paths A-B-C and A-C, and
the bitrates are A-C=100M A-B=300M B-C=300M, we might choose the longer path
A-B-C although the headers overhead occur twice and the A-C path is better,
even at a slower bitrate.

2) Interoperability. If we want a path from A to C, which can use
intermediaries B1 or B2, the datarate through B1 is worse than B2 but metric
does not include overhead, and B2 from a non-Linux provider includes
overhead, then A might choose the bad path A-B1-C instead of the good path
A-B2-C
 
> 
> Getting device_constant as a function of current protection parameters
> and channel type (ie. actual channel access overhead) however, makes
> sense.

I fully agree ! 

Jean-Pierre