Почему майнинг-пул отклоняет shares: причины rejected и stale shares и как снизить reject rate

Майнинг-пул отклоняет share, если не может засчитать ее как корректную работу текущего задания. Чаще всего rejected shares появляются из-за задержек и разрывов соединения, отправки результата по уже устаревшему заданию, ошибок ASIC или нестабильных настроек оборудования. Ошибки в параметрах Stratum тоже создают проблемы, хотя неверный адрес, порт или worker ID чаще приводят к невозможности подключения, а не к небольшому постоянному reject rate.

Stale share — частный случай непринятой работы: ASIC отправил результат для задания, которое уже перестало быть актуальным. Обычно это происходит после смены задания пулом, например при появлении нового блока, когда новое задание дошло до майнера или найденная share вернулась на сервер с задержкой.

Единичные rejected shares возможны и при исправной работе. Проблемой становится устойчивый рост их доли. В Promminer Pool диагностическим ориентиром считается rejection rate не выше 2%; при этом стремиться нужно не к самому порогу, а к минимальному и стабильному значению. Если показатель заметно вырос относительно обычного уровня или держится выше 2%, стоит искать причину.

Promminer Pool — российский майнинг-пул с низкой латентностью (<1 мс в РФ), поддержкой отчётности для ФНС, индивидуальной комиссией, удобным приложением и круглосуточной русскоязычной поддержкой.

Что такое accepted, rejected и stale shares

Share — результат вычислений ASIC, соответствующий сложности, заданной пулом. По поступающим shares пул оценивает объем выполненной воркером работы.

Accepted share — результат, который пул признал корректным и принял.

Rejected share — результат, который пул получил, но не принял. Причины могут различаться: устаревшее задание, некорректный или дублирующийся результат, проблемы соединения или ошибки на стороне оборудования.

Stale share — результат, который мог быть корректным для предыдущего задания, но поступил после того, как это задание потеряло актуальность.

Stale не всегда отображаются отдельной строкой: конкретный пул может учитывать их внутри общей статистики rejected. Поэтому проценты rejected у разных пулов нельзя напрямую сравнивать, не зная их методики учета.

Важно и то, что простое количество shares не равно хешрейту. Пулы могут назначать разную сложность share, поэтому для диагностики полезнее смотреть на reject rate, длительный пуловый хешрейт и динамику конкретного воркера, а не на абсолютное число отправленных результатов.

Почему появляются rejected и stale shares

Причину удобнее искать по характеру проблемы.

Задержка между ASIC и пулом

Для майнинга важна не высокая пропускная способность интернет-канала, а быстрый и стабильный обмен Stratum-сообщениями.

Когда пул отправляет новое задание, ASIC должен получить его как можно быстрее. Если передача задерживается, устройство некоторое время продолжает работать по старому заданию. Аналогично найденная share может стать stale, если слишком долго идет от ASIC до пула.

На результат влияют сразу несколько сетевых параметров:

• latency — задержка передачи данных;

• jitter — колебания задержки;

• packet loss — потеря пакетов;

• стабильность Stratum-сессии — отсутствие частых разрывов и повторных подключений.

Поэтому один показатель ping не дает полной картины. Низкий средний ping мало помогает, если маршрут периодически теряет пакеты или задержка резко увеличивается. География серверов пула важна именно потому, что более короткий и стабильный маршрут снижает риск поздней передачи задания или share.

Нестабильная сеть на площадке

Проблема не обязательно находится между дата-центром и пулом. Потери могут возникать внутри самой площадки: из-за кабеля, порта коммутатора, сетевого оборудования, нестабильного маршрутизатора или интернет-канала.

Хороший диагностический признак — количество затронутых воркеров. Если reject одновременно вырос у большой группы ASIC, в первую очередь стоит проверять общую сеть. Если проблема есть только у одного устройства, вероятнее локальная причина.

Ошибки ASIC и нестабильные настройки

Нестабильная работа ASIC тоже может приводить к непринятым результатам. Причиной могут быть перегрев, проблемы прошивки, нестабильность хеш-плат или слишком агрессивные пользовательские настройки частот и напряжения.

Особенно показателен рост reject после изменения режима работы или прошивки. В таком случае имеет смысл сравнить статистику с предыдущей заведомо стабильной конфигурацией.

При этом нельзя считать любой hardware error причиной rejected share: часть ошибок ASIC обнаруживает локально и вообще не отправляет такой результат пулу. Поэтому состояние оборудования нужно оценивать по совокупности логов ASIC, локального хешрейта и статистики пула.

Promminer также относит нестабильную сеть, перегрев и проблемы прошивки к причинам, которые стоит проверять при повышенном rejection rate.

Неверные настройки подключения

Ошибочный Stratum URL, порт или worker ID обычно проявляются не как небольшой reject rate, а как отсутствие подключения, ошибки авторизации или постоянные переподключения.

Если ASIC не появляется на пуле или не отправляет accepted shares, нужно проверить:

• Stratum URL и порт;

• имя аккаунта и формат worker ID;

• параметры авторизации;

• поддерживаемый алгоритм;

• сетевую доступность сервера;

• основной и резервные адреса пула.

Если устройство нормально подключено и большинство shares принимается, а небольшая часть регулярно отклоняется, причина чаще связана с качеством соединения или стабильностью самого ASIC.

Какой reject rate считать высоким

Универсального процента, одинакового для всех пулов и условий, нет: на показатель влияют методика учета и качество соединения. Практический принцип простой — reject rate должен быть низким и стабильным.

Для Promminer Pool ориентир — не выше 2%. Это верхний диагностический порог, а не нормальный уровень, к которому нужно стремиться. Чем меньше доля отклоненной работы, тем лучше.

При этом динамика иногда важнее абсолютной цифры. Если воркер длительное время работал, например, с очень низким reject, а после замены провайдера или изменения настроек показатель увеличился в несколько раз, это уже повод для проверки, даже если он остается ниже 2%.

Короткий всплеск сам по себе менее показателен. Для оценки устойчивой проблемы лучше анализировать длительный интервал и сопоставлять reject с хешрейтом и состоянием воркеров.

Высокий reject имеет практическое значение: ASIC уже потратил время и электроэнергию на вычисления, но непринятая работа, как правило, не участвует в начислении вознаграждения.

Что проверять, если reject rate вырос

Диагностику лучше проводить последовательно — от статистики пула к сети и конкретному ASIC.

1. Определите масштаб проблемы.
Сравните несколько воркеров. Рост reject у всей группы указывает прежде всего на общую сеть или маршрут до пула. Один проблемный ASIC — на локальное подключение или устройство.

2. Посмотрите длительный пуловый хешрейт.
Краткосрочный показатель меняется из-за статистической случайности поступления shares. Если за длительный период пуловый хешрейт устойчиво ниже локального, проверьте rejected/stale и простои.

3. Определите тип отклонений.
Рост stale в первую очередь указывает на позднюю передачу работы. Для других rejected нужно смотреть сообщения Stratum и логи оборудования: само слово rejected не определяет причину.

4. Проверьте качество сети.
Оценивайте не только средний ping, но и packet loss, скачки задержки, разрывы Stratum-сессии и частоту переподключений.

5. Проверьте конкретный ASIC.
Если проблема локальная, изучите журнал устройства, температуры, состояние хеш-плат, сетевое подключение и последние изменения прошивки или режима работы.

6. Сопоставьте проблему с изменениями.
Если reject вырос сразу после смены провайдера, маршрутизатора, прошивки, разгона или Stratum-адреса, это помогает быстро сузить круг причин.

Такой порядок эффективнее случайной смены настроек: сначала определяется, где возникает проблема — в сети, маршруте до пула или самом ASIC.

Как снизить rejected и stale shares

Способ снижения reject rate зависит от причины.

При повышенном stale rate нужно прежде всего улучшать соединение с Stratum-сервером: использовать стабильный маршрут, устранять packet loss и регулярные разрывы, проверять локальную сеть и выбирать подходящий сервер пула.

Если проблема возникает только у одного ASIC, нужно проверить устройство, его сетевой кабель и порт, температуры, прошивку и режим работы.

Если reject вырос после разгона или изменения настроек, стоит проверить работу на более консервативной стабильной конфигурации. Более высокий локальный хешрейт не дает преимущества, если одновременно увеличивается доля непринятой работы.

Если оборудование регулярно теряет соединение с пулом, проверьте основной и резервный Stratum. Резервное подключение желательно тестировать заранее: факт появления accepted shares подтверждает, что ASIC действительно может на него переключиться.

Как отслеживать rejected shares в Promminer Pool

В Promminer Pool статистику можно анализировать по отдельным воркерам. Интерфейс показывает хешрейт за 5 минут, 1 час и 24 часа, статус оборудования, reject за 24 часа, uptime и время последней отправки share. Это позволяет отличить проблему одного ASIC от общей проблемы площадки.

Для первичной диагностики достаточно трех шагов:

1. проверить, у каких воркеров вырос reject;

2. сопоставить его с длительным пуловым хешрейтом;

3. определить, совпало ли изменение с сетевыми сбоями или проблемами конкретного ASIC.

Для российских площадок имеет значение и расположение серверной инфраструктуры. Promminer Pool использует 10 серверов на территории России. Более короткий маршрут до Stratum может уменьшать влияние сетевой задержки, однако сам по себе не устраняет packet loss, проблемы локальной сети или нестабильность ASIC.

Главный ориентир — не абсолютное отсутствие единичных rejected shares, а низкий и стабильный reject rate. Если он устойчиво растет, сначала определите масштаб проблемы и тип отклонений, затем проверьте соединение с Stratum, локальную сеть и состояние ASIC. Рост stale прежде всего направляет диагностику в сторону задержки и стабильности связи, а reject только на одном воркере — в сторону самого устройства или его подключения.