> É 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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd