[GTER] duvida ntpd + atraso

Antonio Carlos Pina antoniocarlospina at gmail.com
Tue Oct 7 10:57:59 -03 2008 

Certamente em máquinas virtualizadas você terá problemas.

Entenda que, diferente do que pode se pensar, um 1 core só executa 1
instrução por vez. A impressão de multitarefa é para humanos.

Serviços que dependem do clock exato para cálculo de tempo real serão sempre
afetados pois não estão recebendo todos os ciclos de clock no tempo certo (o
clock "desliza" no ponto de vista do aplicativo). Isso é esperado em
sistemas virtualizados (vmware, xen e os "cloud computing" fakes que vemos
por aí).

Não sei se alguém já pensou em um algoritmo que compense essas variacões,
acertando continuamente a base de tempo, mas perceba que se a "base" varia
(o clock) no ponto de vista da aplicação, ele não tem como acertar, não é ?

Abs

2008/10/7 Paulo César Naves Mota <pcnmota at gmail.com>

> Bom dia Antônio,
>
>        Obrigado pelas informações, porém já fiz testes utilizando o iburst
> também e ainda tive os mesmos problemas:
>        - Usarei como servidor NTP uma máquina virtual em cima de VMWare ESX
> 3.0.x. O que tive lendo à respeito é que o ciclo de clock em máquinas
> virtualizadas é diferente, gerando um problema quando esta máquina
> virtualizada está processando outra coisa, por exemplo, o meu ntpd vai
> funcionando normalmente, mas se o squid começa a funcionar, ele começa a
> atrasar e vai atrasando, chegou a um ponto de 20 minutos de atraso. Em
> algumas documentações da própria VMWare, obtive as informações que lhe
> passei.
>        No momento estou testando uma conf passada pela vmware, mas quando
> rodei o sysreport, o horário atrasou também. Não sei o que fazer... Acho
> que
> o jeito será utilizar de uma máquina física para ser o meu servidor ntp.
> Meu ntpd.conf atual:
> # ntpd.conf
> tinker panic 0
> restrict 127.0.0.1
> restrict default kod nomodify notrap
> ntp.dominio.com.br
> driftfile /var/lib/ntp/drift
> logfile /var/log/ntp
>
> [root at server etc]# cat /etc/ntp/step-tickers
> ntp.dominio.com.br
>
> [root at server etc]# ntpq  -p
>     remote           refid      st t when poll reach   delay   offset
> jitter
>
> ==============================================================================
> *máquina.dominio .LOCL.           1 u  158 1024  377    4.031   10.905
> 23.267
>
>
>      Utilizei o próprio comando ntpdate de uma terceira máquina para checar
> o horário no meu ntp server e no servidor que ele se atualiza:
>
>    sudo ntpdate -v meuNTPserver; sudo ntpdate -v OutroServidor
>  7 Oct 08:50:49 ntpdate[25019]: ntpdate 4.2.4p4 at 1.1520-o Fri Mar  7
> 20:24:08
> UTC 2008 (1)
>  7 Oct 08:50:49 ntpdate[25019]: adjust time server IP  offset -0.123052 sec
>  7 Oct 08:50:49 ntpdate[25020]: ntpdate 4.2.4p4 at 1.1520-o Fri Mar  7
> 20:24:08
> UTC 2008 (1)
>  7 Oct 08:50:50 ntpdate[25020]: adjust time server IP offset -0.032444 sec
>
>     Neste caso está legal, porém como disse antes, se ponho processamento
> na máquina, em poucos segundos de processamento ele já atrasa minutos e por
> ai vai...
>
>      Obrigado à você e à todos !!
>
>
> 2008/10/6 Antonio M. Moreiras <moreiras at nic.br>
>
> > Paulo,
> >
> > Você pode "acelerar" esse tempo usando o parâmetro *iburst*, para cada
> > servidor no ntp.conf.
> >
> > Esses 4 minutos correspondem ao tempo que o seu ntpd leva para sentir-se
> > seguro quanto ao bom caráter de suas referências, o que exige algum
> > relacionamento. Antes disso, ele não vai fornecer o tempo para seus
> > próprios clientes. O iburst incrementa a troca de pacotes inicial, toda
> > a vez que o ntp é (re)iniciado, e serve justamente para que ele ganhe
> > confiança em seus interlocutores mais rapidamente, diminuindo esse tempo
> > para aproximadamente 10s.
> >
> > Uma bom exemplo de configuração (ntp.conf) para o seu servidor seria:
> >
> > #---------------------------------------------------------
> > # "memoria" para o escorregamento de frequencia do micro
> > # pode ser necessario criar esse arquivo manualmente com
> > # o comando touch ntp.drift
> > driftfile /etc/ntp.drift
> >
> > # estatisticas do ntp que permitem verificar o historico
> > # de funcionamento e gerar graficos
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> >
> > # servidores publicos do projeto ntp.br
> > server a.ntp.br iburst
> > server b.ntp.br iburst
> > server c.ntp.br iburst
> >
> > # outros servidores bem comportados
> > server ntp.on.br iburst
> > server santuario.pads.ufrj.br iburst
> >
> > # configuracoes de restricao de acesso
> > restrict default kod notrap nomodify nopeer
> > #--------------------------------------------------------
> >
> > Para tentar ajudá-lo no outro problema, gostaria que você postasse
> > alguns dados adicionais:
> > - o ntp.conf que está usando
> > - o resultado do comando "ntpq -p"
> >
> > E gostaria também de entender também como você mediu o atraso.
> >
> > Você conhece o site ntp.br (http://ntp.br)? Se não, gostaria de sugerir
> > que desse também uma olhada na documentação e exemplos de configuração
> > que há lá.
> >
> > Por fim, é bom lembrar que o ntpdate está depreciado e seu uso não é
> > recomendado. Na grande maioria dos casos é mais apropriado rodar o ntpd
> > em todos os clientes.
> >
> > []s
> > Antonio M. Moreiras.
> > moreiras at nic.br
> >
> > Paulo César Naves Mota escreveu:
> > > Obrigado aos amigos que responderam,
> > >
> > >        Agora surgiu algo diferente, o servidor começou a atrasar o
> > horario
> > > dele com o server ao qual se atualiza gradativamente e neste instante
> sem
> > > mais nem menos ele se atualizou ... Nao houve perda de comunicacao
> entre
> > > eles, nao houve interacao minha e isto demorou em torno de 2horas.
> > >
> > >        O que acham sobre isso?
> > >
> > > Obrigado!
> > >
> > > 2008/10/2 Samuel Benevides <samuelbenevides18 at yahoo.com.br>
> > >
> > >> Boa tarde,
> > >>
> > >> Esse tempo é um algoritmo do ntp ele não pode ser alterado.
> > >>
> > >> Samuel Benevides
> > >>
> > >>
> > >> --- Em qui, 2/10/08, Paulo César Naves Mota <pcnmota at gmail.com>
> > escreveu:
> > >>
> > >>> De: Paulo César Naves Mota <pcnmota at gmail.com>
> > >>> Assunto: [GTER] duvida ntpd
> > >>> Para: gter at eng.registro.br
> > >>> Data: Quinta-feira, 2 de Outubro de 2008, 11:16
> > >>> Bom dia amigos, possuo um servidor ntpd em minha rede,
> > >>> porém quando eu o
> > >>> reinicio (service ntpd restart) ele funciona tudo legal,
> > >>> porém as máquinas
> > >>> que estão abaixo dele nao conseguem atualizar por pelo
> > >>> menos uns 4 minutos,
> > >>> aparecendo a seguinte mensagem:
> > >>> ntpdate IP_servidor
> > >>> 2 Oct 10:37:54 ntpdate[6972]: no server suitable for
> > >>> synchronization found
> > >>>
> > >>> Após os 4 minutos
> > >>> 2 Oct 10:37:55 ntpdate[6973]: step time server IP_servidor
> > >>> offset
> > >>> -157.620280 sec
> > >>>
> > >>> Há alguma configuração para o ntp.conf para agilizar
> > >>> este tempo?
> > >>>
> > >>> Obrigado!
> > >>>
> > >>> Paulo Cesar
> > >>>
> > >>> --
> > >>> --
> > >>> Att,
> > >>>
> > >>> ---
> > >>> Paulo Cesar Naves Mota
> > >>> Administrador de Redes
> > >>>
> >
>
>
>
> --
> --
> Att,
>
> ---
> Paulo Cesar Naves Mota
> Administrador de Redes
> 11 - 7526-0580
> °v°     "Be Free, Use Linux / FreeBSD "
> /(_)\    Linux Certification LPIC - I
> ^ ^
> "Insanidade é continuar a fazer o que você sempre fez,
> desejando obter resultados diferentes!" (O Monge e o Executivo )
> "Há mais pessoas que desistem do que pessoas que fracassam." Henry Ford
> "Não é só bater na porta certa, mas bater até abrir." Guy Falks
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list