Mining Latency — задержка на определённом участке процесса майнинга, например между отправкой задания пулом и его запуском в машине. Это не универсальная характеристика соединения. Передача, ожидание в очереди, обработка и подтверждение результатов — разные этапы, измеряемые по-разному.
Пул готовит задание для Петра и отправляет его программе для майнинга. Она может передать сообщение через посредника, прокси, до ASIC — чипа, предназначенного для майнинга. Важно фактическое переключение на новую работу, а не только получение сообщения компьютером. Затем машина отправляет shares — частичные результаты, подтверждающие её работу для пула. В Stratum V2, протоколе связи майнинговых устройств, поля channel_id и job_id связывают сообщения с нужным каналом и заданием. Без этой связи можно измерить начало одной работы и конец другой. [1]
Петр запускает ping по диагностическим указаниям Braiins. Так он проверяет, отвечает ли сервер и сколько занимает путь запроса туда и ответа обратно: RTT, или round-trip time. Это полезный первый шаг. Но направления могут иметь разные маршруты и очереди, поэтому деление пополам не измеряет задержку в одну сторону. Ping также не показывает, как долго пул готовит задание или ASIC начинает его выполнять. Хороший результат вполне может сочетаться с медленным переключением работы. [2] [3]
В нашем примере отправитель записывает Tsend = 1000 ms, а получатель Trecv = 1040 ms. Разница равна 40 ms, но часы получателя могут спешить на 30 ms. Простое вычитание тогда не даст реального времени передачи. ms означает миллисекунды, тысячные доли секунды. Поэтому стандарт сетевых измерений RFC7679 учитывает неопределённость синхронизации часов и место создания временной метки. Без этих сведений разница между серверами не доказывает ускорения: возможно, просто по-разному настроены часы. [3]
Чтобы после нового блока не ждать полного задания, Stratum V2 позволяет заранее отправить Future Job. Это работа для будущего продолжения цепочки, а не указание немедленно начинать. SetNewPrevHash активирует её с правильной ссылкой на предыдущий блок и соответствующим job_id. Если подготовленная работа содержит транзакции, новый блок может сделать некоторые из них непригодными для повторного использования, например потому, что уже содержит их. Снижение задержки не оправдывает игнорирование такого конфликта. Быстро начать неправильную работу — не полезная экономия времени. [1]
Петр видит, что share отправлена, но подтверждение приходит позже. В Stratum V2 SubmitShares.Success может объединить несколько принятых shares; намеренная группировка сокращает число сообщений. Поэтому нельзя приписать всё ожидание передаче или утверждать, что пул всё это время не знал результата. SubmitShares.Error также может последовать после дополнительной проверки. sequence_number помогает связать ответ с отправленными результатами. При поиске неисправности различаем получение, проверку и уведомление. [1]
Майнингу также нужно быстро узнавать о публикации блока. Это другой участок, не соединение машины с пулом. BIP152 уменьшает объём данных между узлами: в режиме high-bandwidth узел может сразу отправить cmpctblock, компактное описание блока. Большинство транзакций получатель восстанавливает из собственных данных. Недостающие запрашивает через getblocktxn и получает в blocktxn, что может потребовать ещё одного обмена. Меньше данных не означает отсутствия ожидания и не заменяет полную валидацию — проверку всех правил блока. [4]
Петра интересует обычная работа и случаи, когда что-то зависает. p50/p95 — процентили: они показывают разные части распределения измеренных времён вместо одного среднего. Если упорядочить время от самого короткого до самого долгого, p50 окажется примерно посередине, а p95 — ближе к медленному краю: около 50 % значений будут ниже первой границы, а 95 % — ниже второй. Так можно отличить обычное ожидание от долгих задержек. Но необходимо объяснить, как учитывались недоставленные сообщения. RFC7679 использует предел ожидания Tmax; его превышение не является обычным быстрым измерением. В описанном там расчёте процентилей неопределённые задержки упорядочиваются как бесконечные. Молча исключив их, мы улучшили бы картину лишь на бумаге. Пустая выборка тоже не означает нулевую задержку: данных для вывода нет. [3]
Петр сравнивает одни и те же этапы при похожей нагрузке и за одинаковые по длительности периоды. Для каждого измерения в ms записывает место временной метки, неопределённость часов и соответствующий job_id; ping и RTT учитывает отдельно. Добавляет сбои и отклонённые результаты, чтобы быстрое среднее не скрывало ненадёжности. Затем можно выяснить, поможет ли другой сервер, сеть или настройка машины. Цель — меньше времени на устаревшую работу, а не обещание найти блок. Низкая задержка не меняет случайности майнинга и правил действительности. [1] [2] [3]
Для полной картины прочитайте эту статью вместе с Stale Rate, Block Propagation, Stratum V2, Mining Pool, Bitcoin. На эту статью также ссылаются Stratum V2, Stale Rate.