ath5k_hw_che...eacon_timers(9)

📦 version 7.3.1, in nixpkgs unstable

👑 ath5k_hw_check_beacon_timers — the check-beacon-timers situation

okay so this is from the Kernel API Manual, section 9 (kernel routines, iykyk), and the function we're stanning today is ath5k_hw_check_beacon_timers(9) 💖

✨ NAME ✨

ath5k_hw_check_beacon_timers — literally just checks whether the beacon timers are correct 🎀

🌸 SYNOPSIS 🌸

bool ath5k_hw_check_beacon_timers (struct ath5k_hw *ah , int intval );

🦋 ARGUMENTS 🦋

  • ah — the struct ath5k_hw, your main character struct 💅
  • intval — the beacon interval

🔥 DESCRIPTION 🔥

So bestie, this whole function is a workaround for IBSS mode. A workaround! She's doing her best 🫶

Here's the lore. We have 4 separate HW timer registers (TIMER0 – TIMER3), and they're closely related to the next beacon target time (NBTT). The HW updates these timers separately, based on the current TSF value. Every time the local TSF converted to TU equals the value stored in a timer, the hardware increments that timer by the beacon interval. Cute, right? Iconic, even.

But 💀 — receiving a beacon with the same BSSID can update the local HW TSF at any time, and that's just something we can't avoid, no cap. So if the TSF jumps to a time that's later than the time stored in a timer, that timer won't get updated until the TSF in TU wraps around at 16 bit (which is the size of the timers, fun fact) and finally reaches the time stored in the timer. Not me waiting a whole wrap-around for a timer update 😭

Here's the actual problem: these timers are closely related to TIMER0 (NBTT), and together they define a time "window". When the TSF jumps between two timers (say, ATIM and NBTT), the one sitting in the past gets left behind (not updated, rude) while the one in the future gets updated every single beacon interval. So the window keeps getting larger, until the TSF wraps around like we described and the abandoned timer finally gets updated again. But — and this is the plot twist — because the beacon interval is usually not an exact divisor of the size of the timers (16 bit), an unwanted "window" has developed between these timers! 🙈

This matters especially with the ATIM window, because during the ATIM window only ATIM frames are allowed — no data frames — which creates transmission pauses after each beacon. This whole symptom has been described as "ramping ping", because ping times increase linearly for some time and then drop back down again. And a wrong window on the DMA beacon timer has the exact same effect, so we check for these two conditions. Periodt.

Returns true if O.K. ✅

💜 SEE ALSO 💜

💡 lowkey the whole vibe here: timers drift, windows grow, ping ramps. Check both conditions or the vibes are off. fr fr.

okay that's the whole page, bestie 🧚 this iconic little number lives at ./drivers/net/wireless/ath/ath5k, dated October 2026, and it's filed as ath5k_hw_che...eacon_timers(9) — slay, go check those timers 💅✨🍓

📦 where this page comes from