Stale Rate — частка подій або зваженої роботи, класифікованих як stale у точно визначеній сукупності. Тут ідеться переважно про shares пулу, що надходять або обробляються в застарілому контексті майнінгового завдання.
Після SetNewPrevHash протокол Stratum V2 вимагає перейти на новий попередній хеш; серед підготовлених завдань чинною лишається лише вказана job_id. Тому хеш нижче попереднього цільового значення сам собою не гарантує придатності для поточної роботи. Діагностиці потрібні контекст і зміни завдання, не лише час надсилання. [Stratum V2 — Mining Protocol]
Приклад: зі 100 подань однакової складності 98 прийнято, 1 відхилено як stale та 1 з іншої причини. Частка відхилених stale становить 1%, а загальний rejection rate — 2%. Це різні чисельники, а не допустимі експлуатаційні межі. F2Pool визначає rejection rate від усіх поданих shares. [F2Pool — Rejection and Staled rates]
Braiins переводить share складності d у d базових одиниць роботи. Якщо в прикладі є одна stale share складності 1 та одна прийнята складності 9, частка за кількістю дорівнює 50%, а за вагою — 10%. Порівнювані чисельники й знаменники мають використовувати однакові одиниці та конвенцію складності. [Braiins — Share difficulty accounting]
F2Pool у документації розрізняє оплачувані “Staled” shares і відхилені stale shares без винагороди. Цю політику не можна поширювати на всі пули. Перед перерахунком відсотка у втрачений дохід перевірте категорію, правила приймання та фактичний розрахунок; назви показника недостатньо. [F2Pool — Rejection and Staled rates]
Stratum V2 дозволяє пакетні SubmitShares.Success. new_submits_accepted_count дає число нових підтверджених подань, а new_shares_sum — суму їхніх складностей. Тому кількість відповідей сервера не дорівнює числу прийнятих shares. SubmitShares.Error містить sequence_number і error_code; без розділення причин не кожна помилка є stale. [Stratum V2 — Mining Protocol]
BIP152 описує Compact Block Relay між вузлами P2P, а не облік shares у пулі. Зменшення обсягу даних може впливати на затримку блоків, але саме не дає Stale Rate майнера. Частку конкурентних блоків мережі не можна використати як частку запізнілих подань конкретного worker. [BIP152 — Compact Block Relay]
Моніторинг Braiins розрізняє shares_5m, shares_60m і shares_24h. Для власної частки використовуйте однакові часові вікна й набір workers у чисельнику та знаменнику. Нуль спостережених подань не означає виміряні втрати 0%: частка невизначена. Відсутні відповіді й прогалини моніторингу не стають автоматично stale. [Braiins — Worker monitoring windows]
F2Pool пов’язує stale зі станом мережі, але для інших відмов згадує помилки прошивки й розгін. Braiins відокремлює перевірку досяжності сервера від реальної продуктивності. Аналізуйте журнали завдань, причини відмов і з’єднання за той самий період; сам ping або нижчий загальний відсоток не доводить усунення причини. [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]
Для повної картини прочитайте також Mining Share, Share Difficulty, Mining Latency, Pool Fee. На цю статтю також посилаються Stale Block, Mining Latency.