Mining Latency je časové zpoždění v konkrétní části těžebního provozu, například mezi odesláním zadání poolem a jeho aktivací ve stroji. Není to jedna univerzální vlastnost připojení. Přenos, čekání ve frontě, zpracování i potvrzení výsledku jsou různé úseky a každý se měří jinak.
Pool Petrovi připraví zadání a pošle je do těžebního softwaru. Ten může zprávu předat přes dalšího prostředníka, proxy, až do ASIC, čipu určeného k těžbě. Rozhodující je skutečné přepnutí na nové zadání, ne pouze příchod zprávy do počítače. Stroj pak odesílá shares, dílčí výsledky, jimiž poolu dokládá vykonanou práci. V protokolu Stratum V2, který určuje pravidla komunikace mezi těžebními zařízeními, pomáhají pole channel_id a job_id spojit zprávy se správným kanálem a zadáním. Bez takové návaznosti bychom mohli měřit začátek jedné práce a konec jiné. [1]
Petr zkusí ping podle diagnostiky Braiins. Zjistí tím, zda server odpovídá a jak dlouho trvá cesta požadavku tam a odpovědi zpět: RTT neboli round-trip time. To je užitečný první krok. Směry však mohou mít jinou trasu i jiná čekání, takže automatické dělení dvěma nezměří jednosměrné zpoždění. Ping navíc neukazuje, jak dlouho pool připravuje práci nebo jak rychle ji ASIC začne počítat. Dobrý výsledek proto může existovat vedle pomalého přepínání zadání. [2] [3]
Ve vlastním příkladu zapíše odesílatel Tsend = 1000 ms a příjemce Trecv = 1040 ms. Rozdíl je 40 ms, ale hodiny příjemce mohou být napřed o 30 ms. Samotné odečtení pak není skutečnou dobou přenosu. Jednotka ms znamená milisekundu, tisícinu sekundy. Síťový standard RFC7679 proto počítá s nejistotou synchronizace hodin i s místem, kde vzniká časová značka. Bez těchto údajů není rozdíl mezi servery prokázaným zrychlením; může ukazovat jen jinak seřízené hodiny. [3]
Aby se po novém bloku nečekalo na celé zadání, dovoluje Stratum V2 poslat Future Job předem. Je to práce připravená pro budoucí návaznost, nikoli pokyn hned ji počítat. Zpráva SetNewPrevHash ji aktivuje se správným odkazem na předchozí blok a s odpovídajícím job_id. Pokud připravená práce obsahuje transakce, nový blok může některé z nich zneplatnit pro další použití, například když už je sám obsahuje. Snaha zkrátit latenci proto neopravňuje ignorovat konflikt. Rychlé spuštění nesprávného zadání není užitečná úspora času. [1]
Petr vidí, že share odešla, ale potvrzení přijde až později. Ve Stratum V2 může SubmitShares.Success shrnout více přijatých shares najednou; záměrné dávkování omezuje množství zpráv. Celé čekání na potvrzení proto nelze připsat přenosu ani tvrdit, že pool po celou dobu výsledek neznal. Také SubmitShares.Error může následovat až po dodatečné kontrole. Pole sequence_number pomáhá přiřadit odpověď k odeslaným výsledkům. Při hledání závady oddělujeme přijetí, kontrolu a oznámení výsledku. [1]
Těžba potřebuje také rychle zjistit, že někdo zveřejnil blok. To je jiný úsek než spojení stroje s poolem. BIP152 zmenšuje množství dat při předávání bloků mezi uzly: v režimu high-bandwidth může uzel rovnou poslat cmpctblock, kompaktní popis bloku. Příjemce si většinu transakcí doplní ze svých dat. Chybějící si vyžádá zprávou getblocktxn a dostane je v blocktxn, což může přidat další výměnu. Méně přenesených dat tedy neznamená nulové čekání a není náhradou úplné validace, ověření všech pravidel bloku. [4]
Petra nezajímá jen běžný provoz, ale také chvíle, kdy se něco zasekne. Údaje p50/p95 označují percentily: ukazují různé části rozdělení naměřených časů, ne jen jeden průměr. Když časy seřadíme od nejkratšího po nejdelší, p50 leží přibližně uprostřed a p95 poblíž pomalejšího konce: asi 50 % hodnot je pod první hranicí a 95 % pod druhou. Tak lze odlišit běžné čekání od dlouhých prodlev. Je však nutné uvést, co se stalo s nedoručenými zprávami. RFC7679 používá mez čekání Tmax; překročený interval není obyčejné rychlé měření. Při výpočtu jeho percentilů se nedefinovaná zpoždění řadí jako nekonečná. Vyřadit je bez upozornění by obrázek zlepšilo na papíře. A prázdný vzorek není nulová latence: znamená, že nemáme z čeho soudit. [3]
Petr porovnává stejné úseky, obdobné zatížení a stejně dlouhá období. U každého měření v ms zapisuje místo časové značky, nejistotu hodin a příslušné job_id; ping a RTT vede zvlášť. K časům přidá výpadky a odmítnuté výsledky, aby rychlý průměr nezakryl nespolehlivost. Pak může zjistit, zda pomůže jiný server, síť nebo nastavení stroje. Smyslem je méně času na zastaralé práci, nikoli slib nalezení bloku. Ani nízká latence nezmění náhodnost těžby nebo pravidla platnosti. [1] [2] [3]
Pro nejúplnější obraz čtěte toto heslo společně s Stale Rate, Block Propagation, Stratum V2, Mining Pool, Bitcoin. Opačným směrem na něj odkazují také Stratum V2, Stale Rate.