Mining Latency to opóźnienie w określonej części procesu wydobycia, na przykład od wysłania zadania przez pool do jego uruchomienia w maszynie. Nie jest jedną uniwersalną cechą połączenia. Przesyłanie, kolejki, przetwarzanie i potwierdzanie wyników to różne etapy, mierzone na różne sposoby.
Pool przygotowuje zadanie dla Petra i wysyła je do oprogramowania górniczego. To może przekazać wiadomość przez pośrednika, proxy, aż do ASIC, układu zaprojektowanego do wydobycia. Liczy się faktyczne przełączenie na nowe zadanie, nie samo dotarcie wiadomości do komputera. Maszyna następnie wysyła shares, częściowe wyniki dokumentujące pracę dla poola. W Stratum V2, protokole komunikacji urządzeń wydobywczych, pola channel_id i job_id łączą wiadomości z właściwym kanałem i zadaniem. Bez tego można zmierzyć początek jednej pracy i koniec innej. [1]
Petr uruchamia ping według instrukcji diagnostycznych Braiins. Sprawdza, czy serwer odpowiada i ile trwa droga zapytania tam oraz odpowiedzi z powrotem: RTT, czyli round-trip time. To przydatny pierwszy krok. Jednak oba kierunki mogą mieć inne trasy i kolejki, więc podzielenie wyniku przez dwa nie mierzy opóźnienia w jedną stronę. Ping nie pokazuje też czasu przygotowania zadania przez pool ani jego uruchomienia w ASIC. Dobry wynik może zatem występować obok powolnego przełączania zadań. [2] [3]
W naszym przykładzie nadawca zapisuje Tsend = 1000 ms, a odbiorca Trecv = 1040 ms. Różnica wynosi 40 ms, lecz zegar odbiorcy może spieszyć się o 30 ms. Proste odejmowanie nie da wtedy rzeczywistego czasu transmisji. ms oznacza milisekundy, tysięczne części sekundy. Dlatego standard pomiarów sieciowych RFC7679 uwzględnia niepewność synchronizacji zegarów oraz miejsce nadania znacznika czasu. Bez tych danych różnica między serwerami nie dowodzi przyspieszenia; może wynikać tylko z innego ustawienia zegarów. [3]
Aby po nowym bloku nie czekać na całe zadanie, Stratum V2 pozwala wysłać wcześniej Future Job. To praca przygotowana dla przyszłego powiązania z łańcuchem, a nie polecenie natychmiastowego rozpoczęcia. SetNewPrevHash aktywuje ją z właściwym odwołaniem do poprzedniego bloku i pasującym job_id. Jeżeli zadanie zawiera transakcje, nowy blok może sprawić, że części z nich nie da się już użyć, na przykład dlatego, że już je zawiera. Skracanie opóźnienia nie usprawiedliwia zignorowania tego konfliktu. Szybkie rozpoczęcie błędnej pracy nie jest użyteczną oszczędnością. [1]
Petr widzi wysłaną share, ale potwierdzenie otrzymuje później. W Stratum V2 SubmitShares.Success może zbiorczo potwierdzać kilka przyjętych shares; celowe grupowanie ogranicza liczbę wiadomości. Całego oczekiwania nie można więc przypisać transmisji ani twierdzić, że pool przez ten czas nie znał wyniku. SubmitShares.Error może również przyjść po późniejszej kontroli. sequence_number pomaga przypisać odpowiedź do wysłanych wyników. Przy diagnozie rozdzielamy odbiór, sprawdzenie i powiadomienie. [1]
Wydobycie potrzebuje także szybkiej wiadomości o opublikowaniu bloku. To inny etap niż połączenie maszyny z poolem. BIP152 zmniejsza ilość danych przesyłanych między węzłami: w trybie high-bandwidth węzeł może od razu wysłać cmpctblock, zwięzły opis bloku. Odbiorca uzupełnia większość transakcji z własnych danych. O brakujące prosi przez getblocktxn, a otrzymuje je w blocktxn, co może wymagać dodatkowej wymiany. Mniej danych nie oznacza więc braku czekania ani nie zastępuje pełnej walidacji wszystkich reguł bloku. [4]
Petra interesuje zwykła praca i sytuacje, w których coś się zacina. p50/p95 to percentyle: opisują różne części rozkładu zmierzonych czasów, zamiast jednej średniej. Po uporządkowaniu czasów od najkrótszego do najdłuższego p50 leży mniej więcej pośrodku, a p95 bliżej wolniejszego końca: około 50% wartości znajduje się poniżej pierwszej granicy, a 95% poniżej drugiej. Pozwala to odróżnić typowy czas oczekiwania od długich opóźnień. Trzeba jednak podać, co zrobiono z niedostarczonymi wiadomościami. RFC7679 stosuje granicę oczekiwania Tmax; jej przekroczenie nie jest zwykłym szybkim pomiarem. W opisanym tam obliczaniu percentyli nieokreślone opóźnienia porządkuje się jako nieskończone. Pomijanie ich bez wyjaśnienia poprawiłoby wynik tylko na papierze. Pusta próbka też nie oznacza zerowego opóźnienia, lecz brak podstaw do wniosków. [3]
Petr porównuje te same etapy przy podobnym obciążeniu i w równie długich okresach. Przy każdym pomiarze w ms zapisuje miejsce nadania znacznika czasu, niepewność zegarów i właściwe job_id; ping i RTT prowadzi osobno. Dodaje przerwy w działaniu i odrzucone wyniki, aby szybka średnia nie ukryła zawodności. Wtedy może sprawdzić, czy pomoże inny serwer, sieć lub ustawienie maszyny. Chodzi o mniej czasu na nieaktualną pracę, nie o obietnicę znalezienia bloku. Małe opóźnienie nie zmienia losowości wydobycia ani zasad poprawności. [1] [2] [3]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Stale Rate, Block Propagation, Stratum V2, Mining Pool, Bitcoin. Do tego hasła prowadzą również odsyłacze z Stratum V2, Stale Rate.