O Raspberry Pi mais estável? Precisão de NTP 81% melhor com gerenciamento térmico

 (austinsnerdythings.com)
1 pontos por GN⁺ 2025-11-27 | 1 comentários | Compartilhar no WhatsApp
  • Apresentação dos resultados de um experimento que combinou fixação de núcleo da CPU e estabilização térmica para reduzir a variação de frequência de um servidor NTP baseado em Raspberry Pi
  • Foi observado que mudanças na temperatura da CPU provocam desvio de frequência no oscilador de cristal, e isso foi estabilizado ao manter a temperatura constante
  • Com um processo “time burner” baseado em controle PID, a CPU foi mantida em 54°C, alcançando redução de 81% na variação de frequência e redução de 77% no desvio padrão
  • Ao reservar a CPU 0 exclusivamente para o chronyd e manter a carga térmica nos demais núcleos, o offset do NTP foi melhorado para média de 38ns
  • O experimento sugere a possibilidade de implementar um servidor de temporização de alta precisão e baixo custo para ambientes que exigem precisão extrema, como sincronização temporal precisa e instrumentos científicos

Problema: instabilidade de temporização causada por variações de temperatura

  • O recurso de ajuste dinâmico de frequência (DVFS) do Raspberry Pi é vantajoso para eficiência energética, mas prejudica a sincronização temporal de alta precisão
    • Quando a frequência do clock muda de acordo com a carga da CPU, a taxa de ticks do clock do sistema também varia
  • A frequência do oscilador de cristal é sensível à temperatura e varia em unidades de ppm conforme o calor gerado pela CPU
    • Mudanças de temperatura entre o dia e a noite provocam deriva de frequência
  • Segundo o monitoramento no Grafana, foi observado um offset de frequência de cerca de ±1ppm de acordo com a variação da temperatura da CPU
    • A média do offset RMS ficou em torno de 86ns, indicando espaço para melhorias

Descoberta: o efeito de manter a temperatura constante

  • Foi confirmado que manter a temperatura da CPU constante pode melhorar a estabilidade da frequência
  • A solução é composta por duas partes
    1. Isolamento de núcleo da CPU – atribuir o chronyd e as interrupções PPS apenas à CPU 0
    2. Estabilização térmica – manter os demais núcleos continuamente ativos para preservar uma temperatura constante
  • Quando o sistema de estabilização térmica foi ativado em 17 de novembro de 2025 às 09:10, a oscilação de frequência caiu imediatamente

Solução 1: fixação de núcleos da CPU e prioridade em tempo real

  • CPU 0: uso exclusivo do chronyd e das interrupções PPS
  • CPU 1–3: tarefas gerais e manutenção da carga térmica
  • Configuração de um script de otimização executado automaticamente na inicialização
    • Fixar o modo de ajuste de frequência da CPU em performance
    • Fixar a PPS IRQ(200) na CPU 0
    • Configurar o chronyd com prioridade em tempo real (SCHED_FIFO 50)
    • Aumentar a prioridade do processo ksoftirqd/0
  • O script pode ser registrado em /etc/rc.local ou como serviço systemd

Solução 2: estabilização térmica com controle PID

  • Para manter a temperatura da CPU constante, foi usado um loop de controle PID
    • Temperatura-alvo: 54°C
    • Três processos worker em CPU 1–3 geram carga com cálculos de hash MD5
    • O tempo de processamento e o tempo de espera são ajustados de acordo com o valor de saída do PID
  • Parâmetros do PID
    • Kp=0.05, Ki=0.02, Kd=0.0
    • Como a variação de temperatura é lenta, o termo derivativo (Kd) foi definido como 0
  • Como resultado, a temperatura da CPU foi mantida estavelmente dentro de uma faixa de ±0.2°C

Resultado: melhora na estabilidade de frequência

  • 81% menos variação de frequência, 77% menos desvio padrão e 49% menos offset RMS
  • Offset RMS médio: 85.44ns → 43.54ns
  • Offset RMS mediano: 80.13ns → 37.93ns
  • Mantendo a CPU em 54°C, foi obtida estabilidade de frequência dentro de ±0.14ppm
  • A estabilidade foi mantida mesmo com variações de temperatura ambiente (18.9~22.2°C)

Procedimento de configuração

  • Preparação prévia: é necessário montar um servidor NTP baseado em GPS PPS
  • Instalação dos pacotes obrigatórios
    • linux-cpupower, python3, util-linux
  • Criar o script de otimização de boot /usr/local/bin/pps-optimize.sh e registrá-lo no systemd
  • Criar o script de controle térmico /usr/local/bin/time_burner.py e registrar o serviço
    • ExecStart=/usr/bin/python3 /usr/local/bin/time_burner.py -t 54.0 -n 3
  • Comandos de verificação
    • Confirmar que o governor da CPU está em performance
    • Confirmar a fixação da CPU e a prioridade do chronyd
    • Medir o offset RMS com chronyc tracking (por exemplo, na faixa de 35ns)

Monitoramento e resolução de problemas

  • Monitoramento em tempo real: watch -n 1 "chronyc tracking"
  • Verificar o estado do serviço: sudo systemctl status time-burner.service
  • Ajuste fino do PID
    • Reduzir Kp em caso de oscilação de temperatura, aumentar Ki se a estabilização estiver lenta
    • A temperatura-alvo pode ser ajustada na faixa de 50~60°C
  • O alto uso de CPU (cerca de 90%) é um comportamento intencional

Trade-offs

  • Maior consumo de energia: consumo contínuo de 3–4W (cerca de 15–25kWh por ano)
  • Mais aquecimento: manutenção em 54°C, ainda dentro de uma faixa segura
  • Ocupação de recursos da CPU: uso de 3 dos 4 núcleos
    • Adequado para um equipamento dedicado a NTP, inadequado para ambientes com múltiplos serviços

Áreas de aplicação

  • Sincronização temporal precisa, instrumentos científicos, pesquisa em sistemas distribuídos, testes de rede etc.
  • Para uso geral é excessivo, mas é útil para montar um ambiente experimental de alta precisão e baixo custo

Direções para melhorias futuras

  • Ajuste adaptativo de PID para lidar com mudanças sazonais de temperatura
  • Controle de resfriamento baseado em hardware (como ventoinha PWM) para melhorar a eficiência energética
  • A aplicação de um OCXO (oscilador de cristal controlado por forno) pode eliminar a deriva térmica

Conclusão

  • Um servidor NTP de altíssima precisão foi implementado combinando fixação de núcleos da CPU com gerenciamento térmico por PID
  • Estabilidade de frequência 81% melhor e offset RMS de 38ns
  • O experimento demonstrou a correlação entre gerenciamento térmico e escalonamento em tempo real
  • É um projeto voltado mais para exploração técnica e aprendizado do que para praticidade

Leituras relacionadas

1 comentários

 
GN⁺ 2025-11-27
Comentários do Hacker News
  • Evitar o CPU0 e definir idle=poll na linha de comando do kernel pode trazer melhor precisão
    Como outras interrupções se concentram no CPU0, ele não é adequado para tarefas que exigem alta precisão de temporização
    • Concordo. Na nossa distribuição de SO baseada em Debian, também fazemos otimizações parecidas, como desativar escalonamento de frequência e fixar núcleos
      Há muitas tarefas do sistema no CPU0 que não podem ser movidas, então é muito melhor usar outro núcleo como uma ilha isolada (isolated core)
      A latência do escalonador no nosso núcleo isolado é muito estável: mínimo de 1µs, média de 5µs e máximo de 59µs
    • Boa dica. Vou tentar isso eu mesmo mais tarde hoje
  • Na estação transmissora WWVB, eles isolam termicamente o equipamento com centenas de garrafas de água para evitar variações de temperatura
    Artigo relacionado: Spare Time – JILA
    • Aquela página merece ser compartilhada por si só. É realmente impressionante que eles operem 4 relógios atômicos e que o UPS seja composto por duas baterias de carro e dois faróis
      A massa térmica feita com garrafas de água também é interessante
    • Eu também uso um método parecido. Armazeno água sob uma mesa dentro de um galpão isolado para evitar que congele durante a noite
      É parecido com o efeito de colocar uma pedra quente dentro de um saco de dormir
  • Eu sou o Austin (austinsnerdythings.com). Postei o texto ontem à noite, fui dormir e acordei surpreso ao ver que estava em 1º no HN
    Meu LEA-M8T gera pulsos de tempo a 16Hz, e no chrony eu defini dpoll=-4. Coletar 256 amostras em intervalos de 16 segundos melhorou a estabilidade
    Ao lado da minha mesa também tenho um BH3SAP GPSDO. O Claude modificou o firmware para adicionar um modo flywheel, que continua gerando pulsos mesmo sem GPS PPS
    Também o atualizei para suportar saída TSIP (protocolo Trimble). Vou abordar isso no próximo texto
    Também vou responder aos comentários em breve, e perguntas são sempre bem-vindas
    • Obrigado pelo ótimo texto. Tenho uma configuração parecida, então foi muito útil como referência
      Fico curioso sobre quanta diferença os pulsos de 16Hz realmente fazem. E também queria saber como você envia os dados para o influxdb. Eu uso collectd, mas falta informação
    • Projeto excelente. Fiquei curioso se você colocou o Raspberry Pi em um gabinete
      Mesmo um gabinete metálico pode dar resultados mais estáveis contra variações cíclicas de temperatura causadas por aquecedor ou ar-condicionado
  • Substituir o cristal oscilador barato do Pi por um TCXO pode dar uma frequência muito mais estável
    Documento relacionado: Raspberry Pi StackExchange – troca do oscillator
    Só isso já reduz o drift em 4 a 5 vezes. Fica ainda melhor se combinado com outras técnicas
    • Já li esse texto várias vezes. Também vendem um HAT audiófilo com OCXO para o Pi4
      Mas não confio no meu nível de solda para fazer a troca eu mesmo
    • O preço de um TCXO é surpreendentemente baixo. Alguns produtos da Abracon custavam menos de 2 dólares
  • Isso é um OCXO em escala de SBC. Fico pensando se colocar um dissipador maior ou adicionar massa térmica ao redor do oscilador ajudaria
    Dá para aprender muita coisa mesmo em algo tão simples quanto montar um servidor NTP
    • Recomendo o gabinete metálico da Flirc. A CPU fica em contato direto com o corpo do gabinete, formando uma grande massa térmica
      Dá para ter uma ótima refrigeração passiva sem ventoinha
    • Penso de forma parecida. Colocar um bloco de metal sobre a CPU e o oscilador para aumentar a inércia térmica parece uma boa ideia
      Se a temperatura mudar devagar, o drift do clock também muda devagar, então a correção fica mais fácil
      Mas dissipadores pequenos podem, na verdade, deixar tudo mais sensível às mudanças de temperatura ambiente
    • Também estou considerando adicionar isolamento térmico ao gabinete do Pi
      Isso pode amortecer mudanças bruscas na temperatura do cômodo, como abrir a janela ou a umidade depois do banho, e reduzir o quanto a CPU esquenta sem necessidade
      No fim, o objetivo é manter o calor o mais constante possível
    • Mas dissipar calor demais também pode ter o efeito contrário
      Os outros núcleos já operam perto da temperatura máxima e ajustam automaticamente a velocidade do clock conforme a temperatura
      Resfriamento excessivo pode atrapalhar esse mecanismo interno de controle térmico
  • Também dá para aquecer diretamente o cristal colando nele um resistor e espuma isolante
    Você ainda pode adicionar um transistor controlável por GPIO para manter a temperatura via controle PID
    • Isso já era usado há quase 100 anos. Os fornos de cristal da década de 1950 eram mantidos em torno de 75°C dentro de uma pequena caixa metálica
      Eles eram estáveis porque usavam cristais cortados para que o coeficiente de temperatura ficasse próximo de zero
      Equipamentos modernos ainda usam essa estrutura, e levam cerca de 5 minutos para estabilizar completamente
    • Eu já fiz no passado um experimento de colocar o Pi sobre espuma de embalagem
      Isso reduziu as variações de temperatura ambiente, mas no fim a solução mais garantida é colocá-lo dentro de uma câmara de controle de temperatura
  • Em vez de forçar a CPU a esquentar para manter a temperatura, acho que talvez seja melhor usar um microcontrolador e um oscilador de precisão
    Por exemplo, uma placa STM32 com Ethernet usada como servidor NTP provavelmente seria mais estável
    • Eu também tenho isso. É um BH3SAP GPSDO que comprei no eBay por 70 dólares, com firmware modificado para suportar modo flywheel
      Ele pode fornecer sinal NTP para o Pi, e um STM32 também é possível, mas basicamente não tem Ethernet nativa
    • Em geral, NTP é um processo sensível ao tempo, então um MCU é muito mais estável que um SoC
      O RTLinux também tem recursos para sincronizar o escalonador com o estado de pinos externos
      Mas, quando há muitos processadores, surgem problemas de metastabilidade
      O Pi não oferece garantias de tempo real como um FPGA (Zynq)
  • Eu nunca tinha pensado na ideia de aplicar carga de propósito para manter a temperatura do SoC constante
    Mas, como o consumo de energia é baixo, faz sentido resolver isso com um pouco de desperdício de energia em vez de um sistema de refrigeração complexo
  • Houve um artigo acadêmico relacionado em 2022: USENIX NSDI22 – Najafi
    • Foi um artigo interessante. Eles resolvem o problema de forma mais elegante, modelando a curva de resposta térmica em vez de simplesmente fazer a CPU esquentar
    • Mas esse artigo basicamente só observa a diversidade dos sensores térmicos dentro do servidor
      Detectar jitter com dois sinais PPS é uma técnica antiga, e aprendizado de coeficiente térmico (tempco learning) também existe há décadas
      Falta verificar quão preciso esse tempco aprendido realmente é