Pergunte a hora para cinco pessoas.
Numa sala, você pergunta as horas para cinco pessoas. Ninguém responde "10h00 em ponto": uma diz "umas 10h, pode ser um pouco antes", outra "10h e pouco". Cada resposta é, na verdade, um intervalo.
Colocando os intervalos lado a lado, aparece um trecho em que todos concordam. Esse é o horário que dá para provar. E se uma sexta pessoa disser "meio-dia", ela não cabe em nenhuma sobreposição: fica de fora, e você sabe exatamente quem errou.
Agora imagine que a regra exige saber a hora com precisão de um minuto, e o trecho em comum tem quatro minutos. Você não pode dizer que está certo nem que está errado. A resposta honesta é "não dá para afirmar". É isso que o PLUMB faz com os relógios dos computadores.
Ida e volta, e a metade da viagem.
Para acertar o relógio, o computador pergunta a hora a um servidor pela internet. A pergunta vai, o servidor anota a hora dele e a resposta volta. O problema: não dá para saber quanto tempo levou a ida e quanto levou a volta.
O PLUMB não finge que sabe. Ele calcula o intervalo em que o instante real tem que estar: a metade da viagem de ida e volta, mais a incerteza que o próprio servidor declara. Faz isso com vários servidores independentes e fica com o trecho em que a maioria concorda. Um servidor que destoa fica de fora, com prova de que destoou.
Por fim, compara o intervalo com a régua (por exemplo, ±100 µs da regra europeia para negociação de alta frequência) e dá um de três vereditos: provado dentro, provado fora ou não dá para afirmar.
Um notebook de verdade, 43 horas, 1.728 consultas.
Medimos o relógio de um Mac comum, uma consulta por minuto, a cinco servidores. No começo o relógio adiantava 135,9 partes por milhão, cerca de 11,7 segundos por dia. A primeira medição já mostrou a máquina ~60 ms fora do horário oficial, e a pior divergência chegou a 575 ms, 5.756 vezes a régua.
Depois instalamos um programa de ajuste de relógio (o chrony). Com a máquina ligada sem dormir, o desvio típico caiu de 27,75 ms para 1,90 ms, cerca de 13 vezes melhor, e os casos provados fora da régua caíram de 59,8% para zero.
Mesmo assim o veredito continuou não conforme, e o PLUMB explicou por quê. Pelo Wi-Fi, a incerteza da medição nunca fica abaixo de ±12 ms, 120 vezes mais larga que a régua: o relógio pode até estar bom, mas não dá para provar. E todos os casos provados fora depois do ajuste vieram logo após a máquina acordar do modo de espera.
O programa de ajuste dizia, sobre si mesmo, estar a 140 µs do horário. É o ator falando de si por um único caminho. O PLUMB é o auditor: cinco fontes independentes, sem confiar em nenhuma, e só consegue provar ±12 ms. Separar os dois papéis é justamente o produto.
| Medida | Antes do ajuste (18,5 h) | Depois, ligado sem dormir (12,4 h) | Depois, período inteiro (24,4 h) |
|---|---|---|---|
| Desvio mediano | 27,75 ms | 1,90 ms | 2,00 ms |
| Desvio em 95% do tempo | 366,9 ms | 10,45 ms | 82,0 ms |
| Maior desvio | 472,9 ms | 87,3 ms | 431,0 ms |
| Incerteza mediana da medição | 12,70 ms | 12,18 ms | 12,18 ms |
| Provado fora da régua | 59,8% | 0% | 6,6% |
| Não dá para afirmar | 40,2% | 100% | 93,4% |
| Provado dentro da régua | 0% | 0% | 0% |
A mesma ferramenta, rodando numa máquina com relógio de precisão (PTP, simulada com desvio de ~2 µs e incerteza de ~8 µs), deu conforme. E quando trocamos o veredito de um relatório para "conforme", o verificador refez a conta a partir do dado bruto e reprovou. A ferramenta não tem lado.
Quando o horário vira evidência.
Serve bem
- Negociação de alta frequência: a regra europeia (MiFID II, RTS 25) exige provar o relógio a ±100 µs do horário oficial. O PLUMB entrega a prova, ou diz honestamente que ela não existe.
- Subestações e medição de rede elétrica: a norma IEC 61850 pede 1 µs. O PLUMB atesta se o equipamento caro entrega o que promete (veja o caso do synchrophasor).
- Ordenar eventos com prova: se os intervalos de dois eventos não se sobrepõem, a ordem está provada; se se sobrepõem, a resposta honesta é "não dá para afirmar".
- Perícia: relógio adulterado, GPS falsificado, máquina virtual que perde o compasso. Um salto de +473 ms foi capturado na medição.
Não resolve sozinho
- Não substitui hardware de tempo: pela internet comum a precisão é de milissegundos. Para provar microssegundos, é preciso um caminho melhor (PTP com hardware ou GPS, a partir de uns R$ 500 num Raspberry Pi).
- Caminho desigual: o cálculo supõe que ida e volta levam tempos parecidos. Um atacante no meio do caminho pode quebrar isso sem ser visto por uma consulta só.
O trecho em que o instante real tem que estar, calculado sem confiar em nenhum servidor isolado.
A precisão que a regra exige: ±100 µs para negociação de alta frequência, 1 µs em subestações.
Quando o intervalo é mais largo que a régua. Não é "está errado": é "esta medição não prova nem uma coisa nem outra".
Onde isso pode estar errado.
O piso é a medição
Pelo Wi-Fi, a incerteza nunca cai abaixo de ~12 ms. O PLUMB mostra o problema; para resolver, é preciso um caminho de medição melhor.
Supõe ida e volta parecidas
Se a ida demora muito mais que a volta, o intervalo pode estar deslocado. Várias fontes independentes reduzem o risco, mas não o eliminam.
Um notebook medido
A medição longa foi num Mac comum. O cenário de relógio de precisão foi simulado, não medido em hardware PTP real.
Servidores que mentem juntos
A votação pega um servidor que destoa. Se a maioria mentir do mesmo jeito, a votação acompanha a maioria.
← Telemetria certificada · stickybit.com.br
- Medição própria, 18 a 20 jul 2026: sonda de hora a cinco servidores, 1 consulta por minuto, ~43 h e 1.728 consultas; ajuste pelo chrony a partir de 19 jul, 15h47 UTC.
- MiFID II / RTS 25 (União Europeia): divergência máxima de 100 µs do UTC para negociação de alta frequência. IEC 61850-9-2: 1 µs.
- Votação entre servidores pelo algoritmo de Marzullo; intervalo pelo invariante de correção do NTP (RFC 5905).