Qual é a lógica por trás dos valores padrão para adjtimex --adjust?

Question

O utilitário adjtimex tem um modo --adjust que pode ser usado para comparar o relógio do sistema com o relógio do CMOS, calcule os valores sugeridos para as variáveis de tempo do kernel tick e offset e instale automaticamente esses valores sugeridos.

Por padrão, isso faz 8 comparações ( count ), com um intervalo de 10 segundos entre comparações ( interval ). Os valores sugeridos são instalados automaticamente a cada 3ª comparação, não incluindo os dois primeiros.

Aqui está a saída de amostra de adjtimex --adjust . Todo o processo (com os valores padrão para count e interval ) leva 70 segundos:

                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1391731712      -3.877457
1391731722      -3.879791     -233.4  10000         0
1391731732      -3.882372     -258.1  10000         0   10002   3806862
1391731742      -3.884677     -230.5  10000         0   10002   1999050
1391731752      -3.887348     -267.1  10000         0   10002   4397487
1391731762      -3.887226       12.2  10002   4397487   10002   3599050
1391731772      -3.886892       33.4  10002   4397487   10002   2208425
1391731782      -3.886588       30.4  10002   4397487   10002   2405300

Minha pergunta é: alguém sabe por que esses valores padrão ( count=8 , interval=10 ) foram escolhidos?

Eu acho que quanto maior o intervalo entre as comparações, mais precisas as estimativas que você obteria do desvio entre o sistema e os relógios CMOS. Então, assumindo que nós queremos que o tio siga a duração de 70 segundos para todo o processo, eu teria pensado que count=3 , interval=35 teria sido a escolha óbvia (note que min. 3 comparações são necessárias para obter sugestões valores tick e freq).

Alguém pode lançar alguma luz sobre isso?

    

Answer 1

David L. Mills (O criador do utilitário adjtimex) escreveu alguns artigos sobre o assunto, disponíveis (com referências) aqui as respostas que você está procurando podem ser encontradas em seu artigo: Algoritmos Melhorados para Sincronizar Relógios de Rede de Computadores (1995)

Sua pergunta especificamente questiona por que mais de 3 contagens são feitas (neste caso 8) por um período de 70 segundos. Embora apenas 3 comparações (amostras) sejam necessárias, um número maior de amostras pode ser usado para estabelecer um intervalo de confiança de 95% de um valor que estima a Deriva Sistemática do relógio.

Os valores calculados de tick sugeridos são instalados após cada 3ª comparação para refinar ainda mais a precisão do desvio estimado.

Estatisticamente, quanto mais amostras você tirar, por um intervalo mais longo, mais próximo do valor atual de desvio você será.

Uma história divertida dos documentos do Dr. Mill: No projeto original do Unix, um timer de hardware interrompe o kernel a uma taxa fixa: 100 Hz no kernel SunOS, 256 Hz no kernel Ultrix e 1024 Hz no OSF / 1 núcleo. Como o intervalo do temporizador Ultrix (recíproco do taxa) não divide uniformemente um segundo em microssegundos, o kernel adiciona 64 microssegundos uma vez por segundo, então a escala de tempo consiste em 255 avanços de 3906 µs mais um de 3970 µs

O modelo de relógio Unix 4.3bsd requer um disco rígido periódico ware timer interrupt produzido por um oscilador operacional na faixa de 100-1000 Hz. Cada interrupção causa um incremento tick para ser adicionado à variável de tempo do kernel. O valor do incremento é escolhido para que o contador, mais um deslocamento inicial estabelecido pelo settimeofday () chamada, é igual à hora do dia em segundos e microssegundos. Quando o carrapato não divide o segundo em microssegundos, um acréscimo adicional ao fixtick é adicionado o tempo do kernel uma vez por segundo para compensar a diferença.

"A estabilidade de um relógio é quão bem ele pode manter uma freqüência constante, a precisão é o quão bem o seu tempo se compara com o clock do sistema e a precisão é em quanto tempo o tempo pode ser resolvido. Todos esses fatores precisam ser combinado a "