Leadaxe 评估 lazy pool 提案的探测与能耗边界

Leadaxe 认为该提案的价值在于减少休眠节点唤醒，但指出现有模型已按 tick 探测，并列出相对最佳节点、超时、并行度、死槽位和观测状态等设计缺口，建议先明确目标和收益。

作者原文@Leadaxe
Thanks for the proposal. Before I go into details, one request.
This text is clearly AI-generated. That's fine as a tool, but I need to hear from you, in your own words and in a few sentences: what is your setup (how many nodes, which platform, which interval), what actually hurts today, and what outcome you want. A proposal this formal hides whether there is a real problem behind it, and I can't evaluate a solution without knowing the problem. Please add that as a comment.
Now the substance.
What is worth taking. The idea has one real merit, and the proposal only hints at it between the lines: energy. pool_tolerance > 0 has to probe every node each interval, so it wakes every sleeping node outside the pool (SPEC 020 idle suspend); that's why the docs recommend 0 on Android. A lazy variant that still keeps a quality threshold would close a gap: today you can't have "quality threshold" and "don't wake everyone" at the same time. I read that as the implicit motivation here, but I'd rather hear it from you than guess.
What is already solved. The whole "bounded cycle, explicit start, hard stop, never an unbounded background scan" framing addresses a problem that doesn't exist here. Probing is tick-based (interval), the first-live mode is already lazy and refills holes in batches of pool nodes in parallel, Close() cancels a running probe (SPEC 050), and forced runs are rate-limited. There is no runaway scanning to protect against, so the trigger/state-machine section can go.
What is wrong or missing.
Degradation is measured against the best pool member, not against outsiders. If all pool members are equally slow, nothing ever triggers while much faster nodes sit outside; the pool can only recover via a manual test. The current mode fixes that every tick. That is a real loss and must be stated as such.
degradation_timeout: 60s doesn't fit the model: pool members are probed once per tick (3m default, 15m recommended). Either it is "N consecutive ticks" or it needs extra probes, which defeats laziness.
Strictly one node at a time is too slow: a probe can take 15 s, so a cycle over a few hundred nodes runs for hours inside one tick and blocks the next tick and the manual URLTest. The first-live refill already probes in parallel batches of pool; this would have to do the same.
Dead members are not covered. A dead slot must accept any live node, not only one within tolerance, or the pool keeps a hole while live nodes exist (see SPEC 138).
"Probing all outsiders on every tolerance breach" misdescribes current behaviour: everything is probed every tick; a breach is a result, not a trigger.
sequential_order, least_recently_tested and "current position in the outsider list" in observability are extra state and extra surface for a first version. One key and one last outcome field would be enough.
So: possibly useful as "lazy pool with a quality threshold", not as described. Before this can become a task under FEATURE 007, the goal has to be stated precisely, and then I'd want to check whether it is reachable within the current pool model and what the actual gain would be (how many probes and wake-ups are saved, what is lost in pool quality). Your description of the setup and the problem is the starting point for that.

返回动态列表查看原文