[GTER] OffTopic - NTPD vs OpenNTPD

[Luiz Otavio O Souza]

2015-02-24 19:48 GMT-03:00 Patrick Tracanelli:
>>>>
>>>
>>> Bom dia,
>>>
>>> Um RTC DS1307 custa 6 dólares, tenho ele rodando com Beaglebone Black, pinagem simples e te garante um relógio de baixo custo.
>>
>> É preciso tomar cuidado com o DS1307 porque ele precisa ser alimentado
>> por 5v (não funciona com 3.3v) e apenas as linhas de dados funcionam
>> com 3.3v, o que faz com que ele funcione na RPi ou na BBB, porém é
>> preciso tomar cuidado e retirar quaisquer resistores pullup que
>> estejam conectados no 5v de alimentação do RTC.
>>
>> Existem outras soluções 3.3v como o DS1338, DS1339, DS3231, etc.
>>
>> Outro problema é que nesse caso o RTC somente prove a referencia de
>> data e hora quando o sistema boota (data e hora atual), mas não
>> fornece uma referencia precisa de clock (não faz diferença a precisão
>> do RTC pois depois do boot o sistema mantém o horário por meios
>> próprios - timers do SoC - não usando qualquer referencia do RTC).
>>
>> Luiz
>
> Grande aula Luiz!
>
> Fora a voltagem tem outra vantagem nos outros modelos? Eu so uso o DS1307 pq tenho facilidade de comprar. A pingam fiz conforme instruções do site da Adafruit. Uma BBB com RTC fica devendo o que, pra um server convencional em relação a clock? Eu pessoalmente acho que o próprio RTC não faz diferença, depois que voce sobe o daemon NTP ele faz o trabalho direitinho. Ja forcei na BBB o kern.hz=2500 e vi que ela passou a perder referência de horário, com divergência de 2 segundos a cada 2:40. Com kern.hz=250 ou 333 não tinha esse deviation.

Alguns só mudam a tensão, mas o DS3231 apresenta diferença na precisão
com uma solução integrada (com cristal e compensação de temperatura)
que garante precisão de +- 2PPM (63 segundos no ano).

A data e hora do RTC é lida apenas no boot para inicializar a data
atual do kernel e a partir dai, o kernel mantém o horário por conta
propria utilizando algum dos timers disponível no hardware. Esse timer
é incrementado a partir do clock do sistema.

Na BBB (e também na RPi), o clock do sistema é definido por um cristal
conectado no SoC.  Esse cristal, sem compensação de temperatura e em
uma placa que custa US$ 35,00 acaba não gerando freqüências precisas e
por isso o kernel não consegue manter o tempo com grande precisão.

O erro que você viu existe mesmo com hz menor, só demora mais para ser
percebido (o mesmo também acontece com a RPi).

Durante o shutdown do sistema, o RTC é atualizado com a data e hora do
kernel e isso significa que independente da qualidade do seu RTC, se o
kernel não foi capaz de manter o tempo sincronizado (sem um cliente
NTP por exemplo), você vai sobre-escrever a data e hora com o valor do
kernel (que esta sempre incrementando o erro).

Então mesmo com o RTC, só o uso de um cliente NTP vai ser capaz de
garantir a estabilidade do relógio do sistema a curto e longo prazo.

A qualidade do RTC só interfere na precisão do relógio quando o
sistema esta desligado.

A solução para isso esta, por exemplo, nos equipamentos da symmetricom
(agora microsemi) que utilizam uma FPGA que recebe uma (ou mais)
fonte(s) de clock estável (rubidium, GPS, relógio atômico) e gera os
vários sinais de referencia e, entre eles, o sinal de clock para o SoC
ARM.

Com essa configuração o timer do sistema é incrementado com uma
freqüência precisa, em fase com o RTC, possibilitando ao kernel manter
o horário em perfeita sincronia com o restante do sistema.

Em um server convencional o RTC também é conectado de forma a fornecer
uma referencia de clock (32KHz) para pelo menos um dos timers no
hardware:

Event timer "i8254" frequency 1193182 Hz quality 100
Event timer "RTC" frequency 32768 Hz quality 0       <====
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
[...]
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0

>
> No entanto com HZ alto o ntimed passou a manter o horário direitinho, sem divergência.
>
> O mesmo eu não posso dizer do NTPD nativo ou OpenNTP que chegam a atrasar, apesar de convergir rapido depois.
>
> Por isso sempre repito e espero ser ouvido (hehe) usem o ntimed. Ou ao menos se tomarem outra decisão, testem/comparem antes de optar por NTPD nativo ou OpenNTP, se o seu interesse é ser daemon cliente.

Com um cliente NTP é esperado que o relógio mantenha-se sincronizado e
com boa precisão (um pouco menor no caso do openntpd).

Mas para quem precisa de um servidor de tempo local, parece que a
única alternativa ainda é o ntpd.

>
> Luiz, aproveitando sua ilustre presença ainda estou precisando de uma solução limpa pra usar o DHT11, sem AVR, se conseguir evoluir com isso me fala. Quero meter o DHT11 na proto cape e simplesmente usar via GPIO mesmo.
>
> É o ultimo passo pra um Data Center utility box hehe :-) hoje tenho sobre uma Beaglebone Black:
>
> - Sensor de Presença (PIR 8630)
> - Sensor de Distancia (SR04)
> - IP Power pra régua com 8 tomadas (feito in-house com relés de 3.3v)
> - Console Server pra 8 máquinas ServerU ehehe (feito in-house)
> - RTC Clock DS1307
> - Sensor de Temperatura e Humidade (com AVR) DHT11
> - Sensor de fumaça (MQ2)
>
> O que me incomoda é só o AVR sujando a solução e demandando um case maior do que eu tenho aqui :(

Agora talvez seja possível utilizar o DHT11, eu adicionei suporte a
interrupções nos pinos de GPIO, o que deve ajudar bastante.

Estou adicionando o driver do DS3231 e do DS1307 (em breve) para
facilitar a vida de quem quer adicionar seu próprio RTC.

Se você tiver mais problemas me avise, estou trabalhando para oferecer
um framework bem mais abrangente e interessante para GPIO no FreeBSD
11.

Luiz

>
> --
> Patrick Tracanelli
>
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> 316601 at sip.freebsdbrasil.com.br
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"