Por que CLOCK_TAI e CLOCK_REALTIME retornam o mesmo valor?

Question

No meu Ubuntu 15.04 (Linux Kernel 3.19.0-28-generic), recebo o mesmo valor ao solicitar CLOCK_TAI e CLOCK_REALTIME com clock_gettime() . Isso é aparentemente um erro porque a diferença entre CLOCK_TAI e CLOCK_REALTIME deve ser o número de segundos bissextos mais a diferença de época considerando este artigo sobre o sistema operacional RedHat.

    

Answer 1

CLOCK_TAI is basically designed as CLOCK_REALTIME(UTC) + tai_offset.  

Portanto, a parte usec / nsec de um timeval / timespec deve ser idêntica.

CLOCK_MONOTONIC: Zeroed at boot.  

CLOCK_TAI = CLOCK_MONOTONIC + tai_mon_offset    

CLOCK_REALTIME(UTC) = CLOCK_TAI - tai_utc_offset  

Mas devido à preocupação com o desempenho (CLOCK_REALTIME é o que os aplicativos martelar mais), no Linux nós realmente estruturamos como:

CLOCK_REALTIME: Initialized at boot from RTC  
CLOCK_MONOTONIC: CLOCK_REALTIME - wall_to_monotonic  
CLOCK_TAI: CLOCK_REALTIME + tai_offset

Então CLOCK_REALTIME and CLOCK_TAI return the same because the kernel parameter tai_offset is zero.

Verifique usando adjtimex(timex tmx) e leia o valor. Eu acho que ntpd irá configurá-lo se for novo o suficiente ( >4.2.6 ) e tiver um segundo bissexto. Ele também pode ser obtido de servidores upstream, mas não consegui verificar. A chamada adjtimex() pode definir tai_offset manualmente quando executada como root.

Minhas referências aqui e aqui

    

Answer 2

A resposta foi encontrada dentro do artigo referido. A ênfase é minha.

  

Para aplicações onde seria possível trabalhar com tempo TAI em vez de UTC, o kernel fornece um relógio CLOCK_TAI especial que inclui segundos bissextos e não precisa ser corrigido após o segundo bissexto, evitando o problema do salto para trás o tempo todo. Ele é implementado como um relógio em execução em um deslocamento integral fixo para CLOCK_REALTIME, que é incrementado atomicamente em 1 quando o clock CLOCK_REALTIME é recuado no segundo bissexto. Ele foi introduzido na versão 3.10 do kernel do Linux e está disponível com os kernels enviados no RHEL7. Por favor, note que o deslocamento de CLOCK_REALTIME é inicializado no boot para zero e nem o ntpd nem o chronyd o definem por padrão para o valor correto (atualmente 35). Mudar para CLOCK_TAI em aplicações naturalmente requer modificações no código e possivelmente também todos os protocolos que usam a representação Unix do tempo.