-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PW_SID:811802] Reduce and optimize quick/roam scan frequencies #289
base: workflow
Are you sure you want to change the base?
Conversation
This is taken care of by the individual cache items and if none exist, tar fails.
Rename to known_network_add_seen_frequency. This prepares to differentiate between tracking frequencies based on a BSS being seen versus being connected to. When a BSS has been connected to that frequency should be preferred when roaming/quick scanning.
This should be called when BSS is connected/roamed to which will insert the frequency ahead of entries which were only seen in scan results. Providing this and the 'seen' variant sets up the frequency list into two adjacent sections: [Most recently used]...[Most recently seen] Doing this will allow scanning to be more optimized and limit the number of frequencies while prefering BSS's that have been connected to prior. Note that this list format is not synced to the file system. Frequencies will be synced in the order of this list but not containing the 'connected' bit. When IWD restarts this information will be lost, but the list is still sorted on disk in a better state than it was prior.
This will allow the BSS frequency to be inserted at the head of the known frequency list, allowing future scans to prefer that frequency.
Allows known frequencies to include the roam BSS frequency and sync.
Known frequencies are stored in order of most recently used, so add some logic to the test to exercise the reordering of frequencies as connections are made.
Since this is meant to be used for quick/roam scans we should be putting a cap on the frequencies scanned. For large networks with many BSS's this could end up scanning quite a few frequencies which isn't very 'quick' as it should be. Since the known frequency list is now sorted in most recently used order we can grab the first 5 frequencies per network and be somewhat confident that this will result in a BSS to connect to.
Fetch PR Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches |
Fetch PR GitLint Output:
Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches Autotest Runner Clang Build |
d7c5f62
to
2526ce4
Compare
c08a6fa
to
1106532
Compare
4f2c8df
to
263e09e
Compare
9eef0d5
to
d3b4175
Compare
68c71d2
to
43f4327
Compare
4170bb4
to
c067bc7
Compare
f10f2fc
to
c2be9ec
Compare
ebbbc93
to
089fa9a
Compare
2192e98
to
43a07cc
Compare
2c7b52e
to
58d64d4
Compare
f7c5ee3
to
38fe7c3
Compare
Rename to known_network_add_seen_frequency. This prepares to
differentiate between tracking frequencies based on a BSS being
seen versus being connected to. When a BSS has been connected to
that frequency should be preferred when roaming/quick scanning.
src/knownnetworks.c | 3 ++-
src/knownnetworks.h | 3 ++-
src/network.c | 6 +++---
3 files changed, 7 insertions(+), 5 deletions(-)