On my Lenovo laptop, fixes that would take over a day to enable and patch on most distros:

  - Wake from sleep

  - Nvidia GSP firmware workarounds and correct version OOTB (proprietary)

    - Mouse lag/jitter
    - External display hotplug
    - DDC/CI over type-c

 - Embedded controller power profiles from taskbar with correct TDP limits for CPU/GPU

 - Battery charge limiter support right from KDE settings

 - Working `switcherooctl` in hybrid graphics mode on AMD

 - Firefox with video decode acceleration (YouTube) on almost all GPU models

Currently using BPFland which makes multitasking as responsive as idle while compiling Yocto/Chromium in the background.

Windows, Mac (mini M1), and kernel built-in scheduler Linux jank and become almost unusable (Ryzen 5800H).

There were no mentions of requirements for 802.11r in the comment. You removed "much faster than K/V." from the quote. "only" was referring to 802.11r exclusively. You can have the same results with different channels with K/V, provided that the clients support it as the rest of the comment mentions.

802.11r-only on different channels is ineffective for devices without K/V, since the reductions are insignificant.

You will be shaving 100ms from a 700ms delay on scan and association, compared to no-scan association which is around 20ms, hence the 75ms note.

And even then, FT is only needed for short buffer streaming like VoIP and VoWiFi. It's more important for WPA3, since handshake roundtrips are even longer (~300ms) which can degrade video/voice internet calls with a lengthy time to recover and complete silence for second or two on VoIP, it's not really needed for the average user back when WPA2 was standard.

Android and iOS will first scan on the same frequency, then rotate through the channels, which is now even longer on 6Ghz capable devices with the total number of channels.

The transition time is significantly faster with equal channels on most hardware, this is where 802.11k helps with different channels, especially in iOS. Without it, they cache scan results provided that the farthest AP is detected, this rarely happens since the scan time is so short.

Scanning different channels while connected causes large amount of jitter on station optimized WiFi SoCs, affecting VoIP on mediocre connections while the user is moving and actively losing signal, so its done as quick as possible, often missing many beacons. They can scan longer on the same channel without degradation. [0]

Without K/V, iOS/Android goes to the extent of doing frequent rescans on low network activity on body movement, you can install a Wi-Fi diagnostic profile to view the current activity on iOS, logcat on "fused" for Android.

The suggestion doesn't bash on 802.11k/v, it's just a compatibility alternative, considering that very few clients support it, let alone off the shelf consumer AP support.

> Setting them to the same channel will cause the APs to interfere (when they can't "hear" each other) or block each other from transmitting, or both. You set APs near each other so they are on non-overlapping bands. Always.

> This is basic WiFi networking 101

This is only true under large air time traffic and in large scale indoor setups. Not satellite APs that are far. Qualcomm, Mediatek and many systems implement their own spatial reuse technology. WiFi 6+ introduces BSS coloring for channel width overlaps to further improve speeds on mixed traffic, not to mention the generally low penetration / TX power of 5Ghz+ on SNR.

>> Samsung is known to push protocol support early: 802.11r in 2013

> 802.11r was released in 2008 and rolled into 802.11-2012.

> Also, the iPhone 5S (2013) has 802.11r support.

The Samsung line in the comment was referring to Androids, many Android didn't support these until 2020, some non-flagship still don't (disabled), Samsung was notable to include it early, there are three paragraphs underneath referring to old phones and smart TVs, both Androids. It is not enabled by default on many off the shelf APs for these reasons.

[0] https://support.apple.com/en-sa/guide/deployment/dep98f116c0...

It's an interesting setup, looking forward to an update.

On iOS, equal channel with correct ESS will switch liberally. On Android 14+ with Broadcom chip it will start conservative, then switch liberally after the first poor signal switch-over event, up until disconnection.

Android (Pixel/Moto) will never switch (even with K/V) on large network activity, only VoIP/video call. It depends on vendor implementation. [0] I use "dp.logcatapp" log reader while roaming, "com.android.location.fused" can be used to show score and current load.

Samsung is known to push protocol support early: 802.11r in 2013, 802.11w 2015, some models do not use Android's default connectivity manager.

To add, WPA3 with 802.11r is known to have issues on Apple hardware before 2021 on all iOS versions, many Android devices, especially smart TVs don't support it, will not connect or are unreliable (protected beacon frame), can be searched in buried report results at OpenWrt forum mega threads and Ubiquity. WPA2+FT and forced MFP with a long password is a safe alternative. 802.11r use PMK push on WPA3 compared to WPA2, which was known to be problematic on older hardware.

802.11K/V is more suitable for campus and load balancing, tuning it based on RSSI and station metrics is very difficult, enterprise hardware rely on network traffic and air time.

[0] https://source.android.com/docs/core/connect/wifi-network-se...

Comments URL: https://news.ycombinator.com/item?id=48175668

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48076643

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47748450

Points: 1

# Comments: 1

I found a workaround by unplugging and replugging as quick as possible, it goes back to ~5.0V.

Comments URL: https://news.ycombinator.com/item?id=47669401

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=47174859

Points: 1

# Comments: 1

[0] https://octopart.com/part/nanya/NT6AN256T32AV-J2

Comments URL: https://news.ycombinator.com/item?id=46948524

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46887507

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46858415

Points: 2

# Comments: 0

Tailscale works with "--tun=userspace-networking" [1].

I had it running on an old phone as a Frigate server with a solar powerbank in remote area, using the 4G as a failover. The uptime is almost a week without solar. Attiny hooked to the power button and a photodiode on the phone flash [2] (blink per minute) used as a watchdog for shutdowns/hangs to hardware reset. The button cap is removed without disassembling the phone.

Old phones are still more efficient than most off the shelf SBCs, especially under load. ~3W compared to 12W with a Pi5 in the same performance ballpark.

[0]: https://github.com/George-Seven/Termux-Udocker https://github.com/indigo-dc/udocker

[1]: https://tailscale.com/kb/1112/userspace-networking

[2]: https://wiki.termux.com/wiki/Termux-torch

Comments URL: https://news.ycombinator.com/item?id=46641745

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46606570

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46561390

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46500602

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46480096

Points: 3

# Comments: 0