Sincroniza o relógio com o NTP enquanto estiver on-line e com o RTC enquanto estiver off-line?

Question

Existe um mecanismo existente que sincroniza um sistema Linux com o NTP enquanto estiver on-line, e com um RTC previsivelmente à deriva enquanto offline?

Operamos "coletores" remotos: sistemas Linux embarcados que coletam e registram o tempo dos dados do sensor. Precisamos que os erros do relógio fiquem razoavelmente pequenos, digamos, abaixo de 5 segundos. Normalmente usamos NTP para sincronizar seus relógios, e isso funciona bem - desde que o sistema esteja online.

O problema é que alguns colecionadores têm uplinks muito ruins que podem ficar inativos por horas, dias ou mesmo semanas. Isso não impede a coleta de dados local, mas sem o NTP, o relógio do sistema Linux se move mal e imprevisivelmente.

OTOH, o RTC do hardware também se move muito, mas a uma taxa constante. A taxa de desvio do RTC varia de uma placa para outra, mas é constante por placa e pode ser medida.

Acho que precisamos de um mecanismo que faça o seguinte:

• Meça a taxa de desvio do RTC de uma placa antes de sua implantação
• Ajusta o tempo do sistema em andamento / regularmente via NTP quando possível
• Ajuste regularmente a hora do sistema a partir do RTC quando o NTP não puder ser utilizado. Tenha em conta a taxa de desvio do RTC.
• Opcional: Medir e registrar a taxa de desvio do RTC em andamento enquanto estiver on-line (1)

Com 'mecanismo' quero dizer alguma parte do software e / ou configuração bem mantida e documentada que possa lidar com os dois estados "online" vs. "offline", garanta que o relógio do sistema esteja sincronizado com o correto time source (ntp vs. rtc), detecta mudança de estado, e corrige o desvio do RTC. Não importa muito se é implementado como uma configuração / plugin ntpd especial, como um daemon separado, como um trabalho cron, ou então.

Eu dei uma olhada em Chrony , mas de acordo com seu documentação tenta prever o desvio do relógio do sistema , que no nosso caso é muito mais imprevisível do que o RTC. O Chrony parece usar o RTC apenas para manter o tempo entre as reinicializações.

(1) Nota O ntpd ativa o '11 -minute mode 'do kernel (atualiza o rtc do clock do sistema a cada 11 minutos). Parece não haver formas com os kernels atuais e com o ntpd para evitar o modo de 11 minutos. Portanto, qualquer informação de drift do rtc é perdida enquanto o ntpd está rodando (thx @billthor).

Atualizações / edições:

• Estamos pensando em adicionar um rádio-relógio externo para o sinal MSF ou DCF77 (estamos baseados na Europa) via USB ou Serial. Mas nós preferimos manter o hardware enxuto.
• Nossos coletores estão localizados em ambientes fechados, geralmente no porão. Então, adicionar relógios GPS não ajudará.
• Nós usamos Debian 7. Isso significa hwclock de util-linux-2.20.1, ntpdate-4.2.6p5, ntpd de ntp-4.2.6.p5, chrony-1.24 (potencialmente 1.30).
• Observe que nosso problema não é que não sabemos como usar ntpdate(8) , hwclock(8) , date(1) , etc. Consulte a seção adicionada em itálico sobre o que eu quero dizer com 'mecanismo'.
• Adicionada nota de rodapé sobre o modo '11-minuto '
• Aqui é uma discussão muito interessante sobre a sincronização off-line e o desvio do RTC

Answer 1

Sua situação é incomum, e eu ficaria surpreso se alguém criar uma configuração padrão baseada em ntpd para fazer o que você deseja. Dito isto, eu gosto de ser surpreendido, e acontece com bastante frequência por estas bandas.

Mas até que alguém tenha uma ideia melhor, você considerou uma entrada crontab como essa?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

IE, a cada cinco minutos tente sincronizar o relógio via ntpdate , e se (e somente se) falhar, ajuste o relógio do hardware para o desvio de acordo com o arquivo /etc/adjtime (cujo formato é detalhado em man hwclock , e cuja primeira linha você preencheu apropriadamente usando seu conhecimento da taxa do RTC em questão), então defina o relógio do sistema a partir do RTC.

Observe que, se você optar por uma solução como essa e estiver implementando um número significativo desses sistemas, será considerado educado trabalhar com o pool e contribuir com os servidores em proporção ao seu uso. Você pode encontrar mais informações no link .

    

Answer 2

O NTP já tem mecanismos para saber se está online ou offline, e mudará para fontes de prioridade mais baixa, conforme necessário. É muito fácil verificar o valor de alcance para acionar uma fonte alternativa, mas eu ficaria com o NTP. Conforme discutido abaixo, o monitoramento e a correção da deriva RTC provavelmente será difícil.

Nos dias anteriores à Internet, usei um programa que ligava para uma fonte de dados e sincronizava o relógio. Pode ainda haver serviços disponíveis que forneçam uma fonte de tempo através de um modem. Isso exigiria o acesso a uma linha telefônica.

Existem problemas conhecidos com o relógio local, que não se aplicam ao RTC. Alguns dos problemas estão documentados na lista de NTP Known OS Issues . Estes podem ser responsáveis pelo seu desvio do relógio. Resolvê-los pode resolver seu problema. Na ausência de carrapatos perdidos, descobri que a fonte de tempo local (sistema) pode ser muito estável.

Você pode usar o driver do relógio Dumb (33) com um programa que grava a hora RTC apropriada no dispositivo / dev / dumbclockX.

Existem vários outros drivers baseados em relógios de rádio. Alguns deles usam serviços de ondas curtas, como WWV e CHU, que podem funcionar em ambientes onde os sinais de GPS não estão disponíveis. Para a Europa, esta lista incluiria BBC, TDF, RBU e RMW.

Pavel Krejci também escreveu um driver RTC, mas não parece estar incorporado aos pilotos oficiais. Isso pode funcionar com a sincronização do tipo PPS.

Deve ser possível medir o desvio do RTC antes da implantação. No entanto, você precisará garantir que o RTC não esteja sendo atualizado automaticamente. Quando o relógio do sistema é atualizado com a função adjtimex, o RTC pode ser atualizado a cada 11 minutos.

O NTP atualizará o relógio quando estiver conectado. Normalmente, o NTP se recusará a fazer grandes ajustes no relógio do sistema. Existem opções para ajustar o quanto o relógio pode ser ajustado.

Eu sugeri opções para usar o RTC acima. Um rádio relógio pode ser mais adequado que um relógio GPS.

Medir a deriva na ausência de uma fonte de tempo confiável para compará-la é provavelmente um esforço fútil. Se a hora local estiver instável, você não poderá usá-la para monitorar o RTC e vice-versa. Medir o desvio enquanto o NTP está conectado não funcionará se o kernel estiver atualizando o RTC a cada 11 minutos. Os RTCs que eu usei têm uma resolução de um segundo, então eles teriam que se deslocar significativamente para serem mensuráveis de forma confiável.