Commit 1be82e6
committed
ieee80211: seed the rate control interval timer when a station is first seen
~AarfRateControl and ~OnoeRateControl create the per-receiver State lazily,
on the first frame to that peer, but left State::timer at zero. The periodic
rate increase tests simTime() - timer >= interval, so for a station first
used after one interval had elapsed (50ms by default) the deadline was
already in the past when its state was created.
The effect in ~AarfRateControl is that the station is bumped a step above
initialRate before its first frame goes out, and two datarateChanged values
are recorded for it at the same instant -- so the configured starting rate
is effectively ignored for every peer. ~OnoeRateControl is milder: computeMode()
returns early while the station has no successful transmission yet, but it
still divides by zero on the way, leaving avgRetriesPerFrame at NaN.
Seeding the timer with the current time at creation makes the interval
measure from when the station was first seen, which is what the periodic
increase is meant to do.
Verified in examples/wireless/hiddennode with ~AarfRateControl,
initialRate=2Mbps and traffic starting at t=1s: the per-station vector
opened with 2Mbps immediately followed by 5.5Mbps at t=1, and now opens with
a single 2Mbps value.
Reported by Devin Review.1 parent 9c5c4d2 commit 1be82e6
2 files changed
Lines changed: 2 additions & 0 deletions
Lines changed: 1 addition & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
46 | 46 | | |
47 | 47 | | |
48 | 48 | | |
| 49 | + | |
49 | 50 | | |
50 | 51 | | |
51 | 52 | | |
| |||
Lines changed: 1 addition & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
31 | 31 | | |
32 | 32 | | |
33 | 33 | | |
| 34 | + | |
34 | 35 | | |
35 | 36 | | |
36 | 37 | | |
| |||
0 commit comments