Mining Latency

O pool prepara uma tarefa para Petr e a envia ao software de mineração. Este pode encaminhar a mensagem por um intermediário, um proxy, até o ASIC, um chip projetado para minerar. O que importa é a mudança efetiva para a nova tarefa, não apenas a chegada da mensagem ao computador. A máquina então envia shares, resultados parciais que demonstram seu trabalho ao pool. Em Stratum V2, o protocolo que organiza a comunicação entre equipamentos de mineração, channel_id e job_id associam as mensagens ao canal e à tarefa corretos. Sem essa ligação, poderíamos medir o início de um trabalho e o fim de outro. [1]

Petr usa ping seguindo o diagnóstico da Braiins. Assim verifica se o servidor responde e quanto a solicitação e a resposta levam para ir e voltar: RTT, ou round-trip time. É um primeiro passo útil. Mas os dois sentidos podem ter rotas e filas diferentes, portanto dividir por dois não mede o atraso em um só sentido. Ping também não mostra quanto o pool leva para preparar a tarefa nem quanto o ASIC demora para iniciá-la. Um bom resultado pode coexistir com trocas de tarefa lentas. [2] [3]

Em nosso exemplo, o remetente registra Tsend = 1000 ms e o destinatário Trecv = 1040 ms. A diferença é de 40 ms, mas o relógio do destinatário pode estar adiantado em 30 ms. A simples subtração não daria então o tempo real de transmissão. ms significa milissegundos, milésimos de segundo. Por isso, a norma de medição de redes RFC7679 considera a incerteza na sincronização dos relógios e o ponto em que se registram os horários. Sem essas informações, uma diferença entre servidores não comprova ganho de velocidade; talvez apenas reflita relógios ajustados de modo diferente. [3]

Para evitar a espera pela tarefa completa após um novo bloco, Stratum V2 permite enviar um Future Job antecipadamente. É trabalho preparado para uma futura ligação à cadeia, não uma ordem de início imediato. SetNewPrevHash o ativa com a referência correta ao bloco anterior e o job_id correspondente. Se a tarefa preparada contiver transações, o novo bloco pode tornar algumas inadequadas para reutilização, por exemplo porque já as contém. Reduzir a latência não justifica ignorar esse conflito. Começar rapidamente um trabalho incorreto não economiza tempo útil. [1]

Petr vê uma share sair, mas a confirmação chega depois. Em Stratum V2, SubmitShares.Success pode resumir várias shares aceitas de uma vez; o agrupamento deliberado reduz o tráfego de mensagens. Não podemos atribuir toda a espera à transmissão nem afirmar que o pool desconheceu o resultado durante esse período. SubmitShares.Error também pode vir após uma verificação posterior. sequence_number ajuda a relacionar respostas e resultados enviados. Ao investigar uma falha, separamos recebimento, verificação e notificação. [1]

A mineração também precisa saber rapidamente que alguém publicou um bloco. Essa etapa é diferente da conexão entre máquina e pool. BIP152 reduz os dados transmitidos entre nós: no modo high-bandwidth, um nó pode enviar diretamente cmpctblock, uma descrição compacta do bloco. O destinatário completa a maioria das transações usando seus próprios dados. Solicita as ausentes com getblocktxn e as recebe em blocktxn, o que pode acrescentar outra troca. Menos dados não significa ausência de espera nem substitui a validação completa das regras do bloco. [4]

Petr se interessa pelo funcionamento comum e pelos momentos em que algo fica travado. p50/p95 são percentis: mostram diferentes partes da distribuição dos tempos medidos, em vez de uma única média. Ao ordenar os tempos do menor para o maior, p50 fica aproximadamente no meio e p95 perto da ponta mais lenta: cerca de 50% dos valores ficam abaixo do primeiro limite e 95% abaixo do segundo. Assim é possível distinguir a espera habitual dos atrasos longos. Mas é preciso explicar o tratamento das mensagens não entregues. RFC7679 utiliza um limite de espera, Tmax; ultrapassá-lo não é uma medição rápida comum. No cálculo de percentis dessa especificação, atrasos indefinidos são ordenados como infinitos. Excluí-los sem avisar melhoraria o quadro apenas no papel. Uma amostra vazia também não significa latência zero, mas falta de base para concluir. [3]

Petr compara as mesmas etapas, sob cargas semelhantes e em períodos de igual duração. Em cada medição em ms, registra o local do carimbo de tempo, a incerteza dos relógios e o job_id correspondente; mantém ping e RTT separados. Acrescenta interrupções e resultados rejeitados para que uma média rápida não esconda falta de confiabilidade. Assim pode investigar se outro servidor, rede ou ajuste da máquina ajudaria. O objetivo é gastar menos tempo em trabalho desatualizado, não prometer encontrar um bloco. Uma latência baixa não muda a aleatoriedade da mineração nem as regras de validade. [1] [2] [3]