Manutenção e Sincronização de Relógio
gn.com.br/linux/clock
Copyright © 2013 Diogo Eduardo Gonçalves Zulli
Todos os direitos reservados. Proibido copiar, reproduzir, distribuir ou publicar sem prévia autorização dos autores.
All rights reserved. It is prohibited to copy, reproduce, distribute or publish without prior permission from the authors.
http://gn.com.br/linux/autores
Introdução
- Este artigo descreve boas práticas relativas à manutenção do relógio de sistemas operacionais Linux. A parte mais importante dessa tarefa depende do software NTP, que teve sua origem por volta do ano de 1980 e trata-se de uma ferramenta muito madura e confiável.
- É um pré-requisito ter o pacote ntp instalado antes de praticar as tarefas descritas neste artigo.
- Os procedimentos podem ser testados nas distribuições derivadas de RedHat (RHEL, Fedora, CentOS, OracleLinux, entre outros).
- Todos os comandos necessitam dos privilégios do usuário root.
- Como os diretórios ou nomes de arquivos podem variar, recomenda-se conferi-los e ajustá-los antes de executar cada comando sugerido.
- A seguir, abordaremos os seguintes tópicos:
- Relógio do Hardware
- Relógio do Sistema
- Relógio do Hardware vs Sistema
- Fuso Horário
- Horário de Verão
- Ajustando o Relógio Imperceptivelmente
- Network Time Protocol - NTP
- Modos de Operação do NTP
- Configuração do NTP em Modo Client
- Configuração do NTP em Modo Server
- Configuração do NTP em Modo Peer
- Configuração de Proxy NTP Transparente
- Monitorando o Sincronismo
- Curiosidades
Glossário
- TIMEZONE ou TZ - Fuso horário;
- GMT (Greenwich Mean Time / Hora Média de Greenwich) - Usado como base para definir os fusos horários;
- UTC (Coordinated Universal Time / Horário Universal Coordenado) - Padrão mais moderno que substitui o GMT;
- DST (Daylight Saving Time) - Horário de verão;
- TZDATA - Nome do pacote de software quem contém os dados sobre fusos horários e horários de verão;
- IANA (Internet Assigned Numbers Authority) - Organização responsável pela coordenação de alguns elementos chave da internet;
- RTC (Real Time Clock / Relógio de Tempo Real) - Dispositivo de hardware que conta o tempo em unidades humanas;
- HWCLOCK (Hardware Clock) - Ferramenta de software para sincronizar o relógio do sistema com o relógio do hadware e vice-versa;
- TICKADJ (Tick Adjust) - Ferramenta de software para ajustar variáveis internas do relógio do sistema;
- NTP (Network Time Protocol) - Protocolo e software para sincronização de relógios;
- NTPD (Network Time Protocol Daemon) - Nome do serviço que mantêm a sincronia de relógios;
- STRATUM - Termo utlizado pelo NTP para classificar o nível de qualidade de um relógio;
- CROND - Software que executa comandos agendados periodicamente;
- SYSLOG - Serviço que grava em arquivos as mensagens de eventos ocorridos em outros serviços ou softwares;
- LOGS - Arquivos ou mensagens gravadas pelo SysLog, geralmente no diretório /var/log;
- IPTABLES (Firewall) - Ferramenta de software para filtragem, roteamento e manipulação do tráfego de rede;
- ENDEREÇO DNS - Nome de domínio que pode ser traduzido em um ou mais endereços IP;
- VIM (Vi IMproved) - Editor de Arquivos de Texto;
Legenda
Comando a ser DigitadoClique para Selecionar a Linha
Conteúdo do Arquivo a ser Editado
Clique para Selecionar o Conteúdo
Resultado dos Comandos ExecutadosExplicação AdicionalRelógio do Hardware
- Mesmo desligado um computador precisa saber sobre o tempo passando, essa responsabilidade é do relógio de hardware (RTC ou hardware clock), que é independente do sistema operacional e geralmente é sustentado por uma pequena bateria.
- Atualmente é muito raro esse relógio apresentar problemas ou esgotar a bateria, mas se ao ser ligado o equipamento estiver com uma data muito antiga pode ser que precise de uma nova bateria.
- Uma boa prática é ajustar esse relógio antes da instalação do sistema operacional, principalmente em equipamentos novos, que podem chegar da fábrica com o relógio errado ou em outro fuso horário.
- Geralmente esse ajuste pode ser feito pressionando uma tecla (DEL, F2, F10, etc.) durante o boot do equipamento.
Relógio do Sistema
- Durante a inicialização, o sistema operacional verifica o relógio do hardware e utiliza sua data e hora como informação inicial para manter seu próprio relógio, chamado de relógio do sistema (system clock), que é independente do relógio do hardware.
- Há, ainda, outras informações que são consideradas pelo sistema operacional, tais como fuso horário e períodos conhecidos como horário de verão.
- Algumas distribuições permitem definir se o relógio de sistema deverá seguir o horário universal ou o fuso horário local.
- Durante a instalação essa opção geralmente é apresentada como "System clock uses UTC".
- Por uma questão de simplicidade, é mais comum não utilizarmos essa opção, assim o relógio do sistema vai ficar igual ao relógio de parede mais próximo.
- As configurações básicas de relógio ficam no arquivo "/etc/sysconfig/clock".
Relógio do Hardware vs Sistema
- Nem o relógio do hardware nem o do sistema podem ser totalmente precisos sem um mecanismo de sincronização, porém o relógio do sistema tende a ser mais confiável. Vamos então criar um script que atualiza o relógio de hardware de acordo com o relógio do sistema, e dessa maneira diminuiremos os possíveis problemas que uma bateria fraca pode causar.
- Lembramos que por padrão o sistema vai executar essa mesma tarefa durante o desligamento normal, entretanto, fazendo isso com mais frequência cobriremos as situações em que o equipamento sofra uma queda de energia ou trave.
- Os procedimentos abaixo criam um script de nome "hwclock-systohc", que será executado automaticamente pelo crond de hora em hora:
touch /etc/cron.hourly/hwclock-systohcchmod 0700 /etc/cron.hourly/hwclock-systohcvim /etc/cron.hourly/hwclock-systohc
#!/bin/sh
export PATH='/bin:/usr/bin:/sbin:/usr/sbin'
hwclock --systohc
exit 0
- Aguardar pelo menos uma hora e depois conferir se o script está sendo executado. Podemos verificar através das mensagens do crond nos logs do sistema, e também verificando a data e a hora de alteração do arquivo "/etc/adjtime", que são atualizadas a cada execução do hwclock :
grep hwclock-systohc /var/log/*cron*ls -l /etc/adjtime/var/log/cron:Jul 11 13:01:01 gn.com.br run-parts(/etc/cron.hourly)[1983]: starting hwclock-systohc
/var/log/cron:Jul 11 13:01:02 gn.com.br run-parts(/etc/cron.hourly)[1984]: finished hwclock-systohc
-rw-r--r-- 1 root root 46 Jul 11 13:01 /etc/adjtime
Fuso Horário
- O fuso horário define em que região do planeta o equipamento está localizado e, assim, determina a hora local pela soma ou subtração de horas ao horário universal.
- Quando o relógio do sistema estiver correto porém com o fuso horário errado, uma tentativa de sincronizar o relógio pode falhar ou ter resultados inesperados, como ajustá-lo com horas de diferença do relógio da parede.
- Se precisar alterar o fuso horário, edite o arquivo "/etc/sysconfig/clock", troque a variável "ZONE=" para o valor correto e depois execute os mesmos procedimentos do tópico "Horário de Verão" deste artigo.
- Os procedimentos a seguir podem ser usados para conferir a configuração atual de fuso horário:
grep ZONE /etc/sysconfig/clockdate "+%:z %Z"zdump /etc/localtimeZONE="America/Sao_Paulo"
-03:00 BRT
/etc/localtime Fri Jul 12 14:02:03 2013 BRT-2:00 FNT Fernando de Noronha (FNST em Horário de Verão)
-3:00 BRT Brasilia (BRST em Horário de Verão)
-4:00 AMT Amazon (AMST em Horário de Verão)
-5:00 ACT Acre (ACST em Horário de Verão)
Horário de Verão
- Muitas vezes esse período de alguns meses é configurado erroneamente, ajustando-se o relógio manualmente no dia definido pelo governo. A maneira correta de ter o relógio ajustado automaticamente e corretamente, tanto no início quanto no fim do horário de verão, é mantendo seu pacote tzdata sempre atualizado.
- Não vamos entrar em detalhes sobre como atualizar um pacote (rpm, yum, etc.), mas faremos essa atualização manualmente usando como fonte o arquivo fornecido pela principal fonte desses dados, o website iana.org, de onde as distribuições obtêm as informações para seus pacotes.
- Os procedimentos abaixo não necessitam de uma tarefa automática, basta que sejam feitos algumas semanas antes da troca de horário - no Brasil, por exemplo, geralmente a troca ocorre em fevereiro e outubro.
- No exemplo a seguir, o fuso horário é "America/Sao_Paulo".
mkdir /tmp/tzcd /tmp/tzwget ftp://ftp.iana.org/tz/tzdata-latest.tar.gztar -zxvf tzdata-latest.tar.gzzic -d atualiza southamericacp -vf atualiza/America/Sao_Paulo /usr/share/zoneinfo/America/Sao_Paulorm -f /etc/localtimecp -vf /usr/share/zoneinfo/America/Sao_Paulo /etc/localtimechmod 0644 /etc/localtimeatualiza/America/Sao_Paulo -> /usr/share/zoneinfo/America/Sao_Paulo
/usr/share/zoneinfo/America/Sao_Paulo -> /etc/localtime
zdump -v /etc/localtime | grep 2013zdump -v /etc/localtime | grep 2014/etc/localtime Sun Feb 17 01:59:59 2013 UTC = Sat Feb 16 23:59:59 2013 BRST isdst=1 gmtoff=-7200
/etc/localtime Sun Feb 17 02:00:00 2013 UTC = Sat Feb 16 23:00:00 2013 BRT isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 20 02:59:59 2013 UTC = Sat Oct 19 23:59:59 2013 BRT isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 20 03:00:00 2013 UTC = Sun Oct 20 01:00:00 2013 BRST isdst=1 gmtoff=-7200
/etc/localtime Sun Feb 16 01:59:59 2014 UTC = Sat Feb 15 23:59:59 2014 BRST isdst=1 gmtoff=-7200
/etc/localtime Sun Feb 16 02:00:00 2014 UTC = Sat Feb 15 23:00:00 2014 BRT isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 19 02:59:59 2014 UTC = Sat Oct 18 23:59:59 2014 BRT isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 19 03:00:00 2014 UTC = Sun Oct 19 01:00:00 2014 BRST isdst=1 gmtoff=-7200Podemos ver que, no dia 20/10/2013 à meia-noite o relógio será será adiantado e no final do dia 15/02/2014 será atrasado. Se acompanharmos, segundo a segundo, o relógio no dia do adiantamento veremos:
Sat Oct 19 23:59:58 BRT 2013
Sat Oct 19 23:59:59 BRT 2013
Sun Oct 20 01:00:00 BRST 2013
Sun Oct 20 01:00:01 BRST 2013
Ajustando o Relógio Imperceptivelmente
- A seguir descrevemos uma técnica obscura para ajustar o relógio do sistema sem que nenhuma aplicação perceba a mudança. Em outras palavras, o relógio será corrigido sem "pulos" de tempo, que podem confundir aplicativos despreparados. A técnica pode ser muito útil quando o relógio está tão errado que o ntp se recuse a sincronizá-lo ou então que possa acarretar um grande pulo no tempo.
- Apesar de o ntp ter opções para sincronizar o relógio mesmo que isso cause pulos, abordaremos essa técnica porque existem situações em que a criticidade da aplicação não nos permite uma parada para manutenção, e muito menos pulos de tempo.
- Basicamente vamos alterar a velocidade do relógio, assim faremos com que o sistema conte o tempo de forma diferente da realidade, mais rápido ou mais devagar.
- O máximo que podemos ajustar é 10% acima ou abaixo do normal.
- Na prática, vamos usar o comando tickadj e alterar seu valor normal de 10000 para mais ou para menos.
- Para adiantar o relógio, definimos o tickadj como 11000, e para atrasar, 9000.
- Os procedimentos descritos a seguir exemplificam a situação em que o relógio está atrasado em 30 minutos em relação à hora certa, então definimos o tickadj em 11000 e aguardamos cerca de 5 horas para que o relógio se acerte.
- Antes de executar os procedimentos abaixo, tenha certeza de que serviços de sincronização de relógio, como o ntp, não estejam em execução.
tickadjtickadj 11000datetick = 10000
tick = 11000
Sat Jul 13 15:03:04 BRT 2013Não encontrei uma maneira de demonstrar através de comandos o desvio do relógio.
Para perceber o relógio adiantando, um outro equipamento deve ser usado como referência.
Minuto a minuto, em um equipamento com tickadj normal teriamos no relógio:
01:01:00
01:02:00
01:03:00
01:04:00
Enquanto que simultaneamente no servidor com tickadj alterado teriamos:
01:01:00
01:02:06
01:03:12
01:04:18
- O processo é bem demorado e tem desvio de aproximadamente 6 segundos a cada minuto. Quando o relógio estiver correto, o valor do tickadj deverá ser redefinido como normal:
tickadj 10000hwclock --systohctick = 10000
Network Time Protocol - NTP
- O ntp é um protocolo para sincronização de relógios com precisão de milisegundos (1ms = 0.001s). Não entraremos aqui em muitos detalhes sobre o funcionamento interno do ntp, vamos somente resumir sua forma de trabalho e seguiremos para sua configuração.
- Para sincronizar o relógio local, o ntp usa outro relógio de melhor qualidade como referência, fazendo pequenos ajustes para manter-se em sincronia.
- Para rotular a qualidade de um relógio, o ntp utiliza sua distância até o próximo relógio com melhor qualidade, e essa distância é contada em níveis, ou stratum.
- Quanto menor o stratum, mais qualidade tem o relógio; sendo assim, um relógio stratum=0 (zero) será a melhor escolha. O stratum=16 é usado para indicar que o relógio não está sincronizado.
- No mundo real, a maioria dos servidores públicos e gratuitos são stratum 1, 2 e 3.
- Ao sincronizar com um relógio stratum=1, seu relógio se tornará stratum=2, e assim por diante hierarquicamente.
- Outro fato importante sobre o ntp é que ele só trabalha a partir do horário universal, ou seja, as configurações de horário de verão e fuso horário devem ser previamente verificadas e corrigidas.
- O projeto pool.ntp.org visa organizar e facilitar o uso de servidores públicos; através de um endereço dns são escolhidos servidores aleatoriamente.
- Em julho deste ano já havia mais de 4000 servidores ativos no projeto e há algum tempo ele já vem sendo utilizado como configuração de fábrica na maioria das distribuições linux.
- O primeiro passo para começar a utilizar o ntp é fazer a sincronização inicial do relógio, escolhendo um servidor da listagem abaixo, e executando o comando ntpdate, conforme o exemplo:
0.pool.ntp.org # Mundial
1.pool.ntp.org # Mundial
2.pool.ntp.org # Mundial
3.pool.ntp.org # Mundial
pool.ntp.br # Brasil
south-america.pool.ntp.org # América do Sul
north-america.pool.ntp.org # América do Norte
europe.pool.ntp.org # Europa
africa.pool.ntp.org # África
asia.pool.ntp.org # Ásia
oceania.pool.ntp.org # Oceaniantpdate pool.ntp.brhwclock --systohc14 Jul 16:04:05 ntpdate[3891]: adjust time server 111.222.33.44 offset -11.011983 sec
Modos de Operação do NTP
Configuração do NTP em Modo Client
- Agora que já preparamos o ambiente e nosso relógio está "quase" certo, podemos configurar os serviços para sincronizá-lo e mantê-lo em sincronia. Devemos então configurar e habilitar os serviços ntpd e ntpdate.
- Algumas distribuições possuem um pacote separado para configuração do ntpdate, como um serviço, que é iniciado antes do serviço ntpd durante o boot, fazendo a sincronização inicial. Em outras distribuições essa tarefa é feita pelo próprio script de inicialização do ntpd, e nesse caso os procedimentos referentes ao serviço ntpdate podem ser ignorados.
vim /etc/sysconfig/ntpdate
SYNC_HWCLOCK=yesSomente alterar a opção acima, o restante pode ficar como estiver.vim /etc/sysconfig/ntpd
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x -g"Acrescentar as opções "-x -g" e manter as demais configurações como estiverem.vim /etc/ntp.conf
# ---
driftfile /var/lib/ntp/drift
restrict 127.0.0.0 mask 255.0.0.0
restrict default nomodify notrap nopeer noquery
# ---
server pool.ntp.br burst iburst
server 0.pool.ntp.org burst iburst
# ---
chkconfig ntpdate onchkconfig ntpd onservice ntpdate startservice ntpd start- A sincronização pode demorar um bom tempo, dependendo de quão errado o relógio está. Para acompanhar o processo, verifique os logs, e os comandos abaixo também podem ser úteis:
ntpstatntpdc -n -c sysinfogrep ntp /var/log/messagesunsynchronised
time server re-starting
polling server every 64 s
. . .
system peer: 0.0.0.0
system peer mode: unspec
stratum: 16
. . .
synchronised to NTP server (111.222.33.44) at stratum 2
time correct to within 21 ms
polling server every 64 s
. . .
system peer: 111.222.33.44
system peer mode: client
stratum: 2
. . .
Jul 15 17:05:06 gn.com.br ntpdate[38910]: step time server 111.222.33.44 offset 0.001983 sec
Jul 15 17:06:07 gn.com.br ntpd[38911]: synchronized to 111.222.33.44, stratum 1
Configuração do NTP em Modo Server
- Muitas vezes, por questões de políticas de acesso ou segurança, as estações de trabalho da rede interna não podem acessar diretamente a internet e, assim, não têm permissão para sincronizar seus relógios pelo ntp.
- Uma solução é configurar um servidor ntp na própria rede, muito comumente no mesmo equipamento do firewall, dns, squid, etc.
- Isso é facilmente habilitado: usando como base a configuração que fizemos no tópico anterior, vamos acrescentar as linhas "restrict", que liberam resposta às requisições da rede local.
- Também vamos acrescentar um relógio "falso" com stratum=9 de referência, para situações em que o próprio servidor não possua acesso à internet ou possua uma conexão instável.
- Esse servidor poderá, então, ser utilizado pela rede interna, sendo suportado por uma grande variedade de equipamentos e sistemas operacionais (Storage, Switch, Router, Windows, etc.).
vim /etc/ntp.conf
# ---
driftfile /var/lib/ntp/drift
restrict 127.0.0.0 mask 255.0.0.0
restrict default nomodify notrap nopeer noquery
# ---
server pool.ntp.br burst iburst
server 0.pool.ntp.org burst iburst
# ---
server 127.127.1.0 burst iburst
fudge 127.127.1.0 stratum 9 refid LOCAL
# ---
restrict 10.0.0.0 mask 255.0.0.0 nopeer nomodify notrap
restrict 172.16.0.0 mask 255.240.0.0 nopeer nomodify notrap
restrict 192.168.0.0 mask 255.255.0.0 nopeer nomodify notrap
# ---
service ntpd stopservice ntpd startConfiguração do NTP em Modo Peer
- Em alguns cenários, são necessários servidores com redundância de serviços, tais como servidores dns, clusters, banco de dados, etc. Para esses casos, o ntp nos permite configurar servidores como backups um do outro, criando associações simétricas-ativas, nas quais cada servidor pode ser tanto server quanto client, dependendo da situação dos seus relógios de referência, ainda assim servindo requisições para seus clients normalmente.
- Uma boa prática em ambientes com vários servidores é configurar todos eles como peers entre si, mesmo que não estejam na mesma localidade.
- Dessa maneira, mesmo que alguns servidores percam seus respectivos relógios de referência, continuarão funcionando com base em referências dos outros peers.
vim /etc/ntp.conf
# ---
driftfile /var/lib/ntp/drift
restrict 127.0.0.0 mask 255.0.0.0
restrict default nomodify notrap nopeer noquery
# ---
server pool.ntp.br burst iburst
server 0.pool.ntp.org burst iburst
# ---
server 127.127.1.0 burst iburst
fudge 127.127.1.0 stratum 9 refid LOCAL
# ---
restrict 10.0.0.0 mask 255.0.0.0 nopeer nomodify notrap
restrict 172.16.0.0 mask 255.240.0.0 nopeer nomodify notrap
restrict 192.168.0.0 mask 255.255.0.0 nopeer nomodify notrap
# ---
restrict 10.0.0.2
peer 10.0.0.2 burst iburst
# ---
Nesse exemplo, o outro servidor (peer) tem o IP 10.0.0.2, e naquele servidor a configuração deve ser idêntica, somente alterando a linha "peer" que deve apontar para o IP deste servidor.Outro exemplo seria um ambiente com 3 servidores, onde cada servidor teria a linha peer de acordo com diagrama abaixo:
# Servidor1 # Servidor2 # Servidor3
restrict 10.0.0.2 | restrict 10.0.0.1 | restrict 10.0.0.1
restrict 10.0.0.3 | restrict 10.0.0.3 | restrict 10.0.0.2
peer 10.0.0.2 burst iburst | peer 10.0.0.1 burst iburst | peer 10.0.0.1 burst iburst
peer 10.0.0.3 burst iburst | peer 10.0.0.3 burst iburst | peer 10.0.0.2 burst iburstservice ntpd stopservice ntpd startntpdc -n -c listpeersclient 111.222.33.44
sym_active 10.0.0.2
Configuração de Proxy NTP Transparente
- Não é o objetivo deste artigo explicar o conceito de proxy ou roteamento, mas sim descrever uma técnica específica para o ntp que pode ser usada para economizar banda de internet em um gateway/firewall, já existente.
- Não encontramos muita documentação sobre o assunto, por isso utilizamos aqui o nome de "proxy transparente".
- A técnica é similar ao modo como as conexões web são interceptadas por um proxy transparente e redirecionadas ao squid, porém aqui vamos redirecionar as conexões de ntp.
- Nenhuma alteração é necessária nas configurações do ntp, é preciso somente criar regras iptables para interceptar as conexões na porta 123 e redirecioná-las para o prório servidor.
- Após serem testadas, as regras devem ser incorporadas às configurações de firewall já existentes.
iptables -I FORWARD -p udp --dport 123 -j DROPiptables -I FORWARD -p tcp --dport 123 -j DROPiptables -t nat -I PREROUTING -p udp --dport 123 -j REDIRECTiptables -t nat -I PREROUTING -p tcp --dport 123 -j REDIRECTAs duas primeiras regras proibem o forward (roteamento/repasse) das conexões ntp.
As duas ultimas regras redirecionam as conexões ntp para o próprio servidor.
Para testar, basta tentar sincronizar o relógio de um outro servidor ou estação especificando um servidor inválido, por exemplo: ntpdate 4.3.2.1
- Dica: Essa técnica também funciona para a porta 53 (dns) se você tiver rodando named ou dnsmasq.
Monitorando o Sincronismo
- Mais importante que configurar corretamente é monitorar o perfeito funcionamento de todos os itens relacionados ao relógio do servidor. A seguir vamos criar um script que verifica os principais aspectos dos tópicos vistos neste artigo e emite alertas quando algo está fora do normal.
- As mensagens de alerta serão gravadas no SysLog e enviadas por e-mail em caso de problemas.
- O script deverá ser agendado para execução periódica no crond.
- Como ele ficou um pouco extenso para ser colocado diretamente neste artigo, optamos por deixar aqui os links para download.
touch /etc/cron.hourly/gncheckclock.shchmod 0700 /etc/cron.hourly/gncheckclock.shvim /etc/cron.hourly/gncheckclock.sh
# download do script em:
# http://gn.com.br/linux/clock/gncheckclock.sh
# ou, compactado em:
# http://gn.com.br/linux/clock/gncheckclock.sh.gz
Alterar a variável ADMIN_EMAIL dentro do script./etc/cron.hourly/gncheckclock.shgncheckclock: /etc/adjtime (hwclock): okgncheckclock: tickadj (10000): ok
gncheckclock: ntpstat (stratum=2): ok
gncheckclock: ok
Curiosidades
- 1 Segundo: é o tempo de 9192631770 ciclos de radiação, correspondentes à transição entre dois níveis de energia do átomo de Césio-133 (Cs), conforme definição oficial da International System of Units em 1967.
- 2013-08: O relógio mais preciso do mundo funciona a base de átomos de itérbio (Yb) na temperatura de -273.14999C (pouco acima do zero absoluto) e raios laser que oscilam 518 trilhões de vezes por segundo (se fosse um processador seriam 518 TeraHertz).
- Ele é o mais preciso pois consegue medir/dividir um segundo e mais partes (casas decimais) que outros relógios atômicos, mas como a definição de "1 segundo" é baseada em ciclos de radiação do césio, nenhum relógio pode (ainda) ser mais considerado mais exato.
- GPS: O princípio do funcionamento do Global Positioning System é simplesmente a medição precisa e exata do tempo. Resumidamente, a triangulação é feita comparando-se o relógio dos satélites "visíveis", como todos os satélites estão com seus relógios sincronizados, a diferença de tempo medida entre eles é o tempo que o sinal demorou para chegar até o receptor. Essas diferenças de nanosegundos são convertidas em distâncias, visto que o sinal viaja na velocidade da luz.
- O sistema é composto de 24 satélites em orbita e 5 estações de controle na Terra.
- Cada satélite possui 4 relógios atômicos.
- Aparelhos de GPS não enviam sinais para os satélites, somente recebem.
