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
Hi Thomas,
> -----Message d'origine-----
> De?: Thomas Pedersen [mailto:[email protected]]
> Envoy??: mardi 16 avril 2013 14:26
> On Mon, Apr 15, 2013 at 3:39 PM, Jean-Pierre Tosoni
> <[email protected]> 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
+ o11s-devel
On Mon, Apr 15, 2013 at 3:39 PM, Jean-Pierre Tosoni <[email protected]> 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