mirror of
https://github.com/esphome/esphome.git
synced 2026-07-10 08:55:36 +00:00
J. Nick Koston
f29da222fe
The 3 ms rate limit was tight enough that the outer feed_wdt_with_time() at the top of Application::loop() hit the slow path on nearly every iteration. On-device measurements showed 95-99.9% of iterations triggering esp_task_wdt_reset(), costing ~9-12 us/hit (BT proxies worse due to WDT spinlock contention with the BT task on the other core). Much worse under wake-storm workloads: with loop_interval_ raised for power saving and an external stack (OpenThread in the reported case) posting frequent wake notifications, the main loop can spin at thousands of Hz doing almost nothing but feeding the watchdog — burning ~26% CPU in the extreme case reported on #15792. Raising the threshold to 300 ms: - Normal 62 Hz loop: feeds once every ~19 iterations (~3 Hz) instead of every iteration. - Wake-storm case: feeds ~3 Hz regardless of wake rate. - Any operation exceeding 300 ms still triggers a real feed right after it finishes (the post-component and post-scheduler-item feeds naturally clear the gate). Safety margins vs platform watchdog timeouts remain large: 16x on ESP32 (5 s task WDT), 5x on ESP8266 soft WDT (1.6 s), 20x on ESP8266 HW WDT.
