[GTER] duvida ntpd + atraso
Paulo Cesar Naves Mota
Paulo.Mota at cetelem.com.br
Tue Oct 7 11:17:38 -03 2008
Antônio,
Acredito que sim, não terá como acertar.
Acredito que agora faremos um desenho diferente, onde usarei como ntp
server o host ESX. Farei os testes, mas como ele é físico, acho que não
ocorrerá problemas.
Abraços!
Antonio Carlos Pina wrote:
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 <mailto:pcnmota at gmail.com>
<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
<mailto: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
<mailto: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 <mailto:moreiras at nic.br> <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 <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 <mailto: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 <mailto:samuelbenevides18 at yahoo.com.br>
<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
<mailto:pcnmota at gmail.com> <pcnmota at gmail.com>
> > escreveu:
> > >>
> > >>> De: Paulo César Naves Mota <mailto:pcnmota at gmail.com>
<pcnmota at gmail.com>
> > >>> Assunto: [GTER] duvida ntpd
> > >>> Para: gter at eng.registro.br <mailto: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
<https://eng.registro.br/mailman/listinfo/gter>
>
--
gter list https://eng.registro.br/mailman/listinfo/gter
<https://eng.registro.br/mailman/listinfo/gter>
--
Att,
Paulo César Naves Mota
Administrador de Redes
CETELEM SERVICOS DO BRASIL LTDA - SP
Av. Paulista, 1106 - 11º Andar
Fone:+55 11 3377-0304
e-mail: paulo.mota at cetelem.com.br <mailto:paulo.mota at cetelem.com.br>
°v°
/(_)\
^ ^
LinuxUser: 412359
More information about the gter
mailing list