234 / 736LAT

Mining Latency

Скільки часу потрібно, щоб отримати й запустити нове завдання

Петр майнить у пулі — сервісі, що об’єднує роботу багатьох майнерів. Коли з’являється новий блок, його машина має вчасно отримати наступне завдання й почати його виконувати. Самого швидкого інтернету недостатньо: повідомлення ще проходить через програми, перш ніж зміняться обчислення. Результати долають схожий шлях у зворотному напрямку. Mining Latency описує затримки на цих шляхах. Щоб число мало зміст, потрібно знати, між якими подіями виміряли час.

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.

DOC · 001Stratum V2 — Mining ProtocolСпецифікація DOC · 002Braiins — Connection diagnosticsДокументація DOC · 003RFC7679 — One-Way Delay MetricСпецифікація DOC · 004BIP152 — Compact Block RelayСпецифікація
Переглянуто: Спочатку джерела · Не інвестиційна порада