[FUG-BR] Estranho comportamento do ping

tg_melo em bol.com.br tg_melo em bol.com.br
Quarta Dezembro 2 02:36:01 BRST 2009


> É normal o relogio atrasar sim (adiantar é incomum), por isso
> acho saudável agendar no cron um ntpdate 1x por dia, e sim
> estou disposto a te ajudar pois já sofri muito e estudei a fundo
> problemas de relógio, principalmente nas epocas dos k6 onde
> era comum (pelo menos nos meus) um erro super esquisito que
> era algo mais ou menos assim "negative calcru of time -1234", que
> significava que o processo XYZ havia terminado sua execução
> em 1234 usecs antes de haver sido iniciado, altamente paradoxal.
> 
> Então, me motivei pois mais ninguém se interessou pelo seu
> problema, e por conhecer a fundo o funcionamento do relogócio
> do PC (desde as epocas dos XT e 286 alterando o ticker do PC
> de 18,2 pra 64 e estragando as unidades de disquete, kkkkk)
> e de sua implementação no FreeBSD, a qual na minha opnião
> é a mais avançada e completa existente.
> É tão completa, que se vc conseguir descobrir que o normal do
> seu relógio é atrasar 228 ticks por dia, vc pode atravez de variaveis
> alterar a taxa de ticks para refletir esse atraso.
> 
> Mas enfim, aqui não é a lista de CHAT pra ficarmos divagando
> sobre o assunto, então pra concluir, te digo o seguinte, as vezes
> a gente se bate um monte pra resolver via software esse problema,
> e nem sempre a solução é decente, e por incrível que pareça, a
> solução definitiva para esse problema, em várias ocasiões em
> que topei com ele, foi a substitução da pilha (não chamem de
> bateria por favor) da BIOS. Foi difícil de eu acreditar no começo
> que a pilha tivesse alguma relação com o funcionamento do
> relógio quando o computador está ligado, mas infelizmente os
> designs das placas mães baratas (leia-se essas que usamos
> nos desktops) são assim mesmo.
> 
> Se esse computador é um servidor em produção que rode algo
> de média importância, sugiro esse teste simples: troque a pilha
> dele com a pilha de algum desktop novo (pra evitar a chance de
> usar outra pilha fraca) ai da empresa, e se der certo reporte o
> resultado para a lista.
> 
> --
> Nilson

fala, Nilson.
apenas adiantando. 
fiz a substituição da pilha, mas como estava sem multímetro em mãos, não tive como testar a q foi utilizada no processo (seria uma pilha mais nova, nunca se sabe...).
realmente apoio sua indicação, e pretendo assegura-la o mais breve possível, tendo certeza da carga.
(meu p133 gateway/downloader/proxy pessoal, q o diga, está suplicando por pilha nova)
ainda assim a perda de pacotes em intervalos de horário não específicos (2 a 4 vezes diárias), permaneceu.
como disse, não chega necessariamente a interferir no funcionamento geral. mas está lá.
ainda suspeito do restante do hardware tb. pq?
parafraseando vc mesmo, "... principalmente nas epocas dos k6 ...".
adivinha só.
é o q sempre digo, o desarmador reconhece a bomba só com a descrição. :D
18,2 pra 64. isso q é um verdadeiro overclock de interrupções. old school :)
no mais, logo q me certificar da carga da pilha já posto os resultados.
[]'s



Gabriel


Mais detalhes sobre a lista de discussão freebsd