NTP 데몬의 상태를 쿼리하면 ntpdc -c sysinfo
다음과 같은 출력이 표시됩니다.
system peer: 0.0.0.0
system peer mode: unspec
leap indicator: 11
stratum: 16
precision: -20
root distance: 0.00000 s
root dispersion: 12.77106 s
reference ID: [73.78.73.84]
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
system flags: auth monitor ntp kernel stats
jitter: 0.000000 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
이는 NTP 동기화가 실패했음을 나타냅니다. 하지만 시스템 시간 정확도는 1초 이내입니다. 지금과 같은 시간 동안 네트워크 연결 없이 시스템을 실행하면 시스템 시간이 약 10초 정도 차이가 납니다.
이 동작은 시스템에 시간을 동기화하는 다른 방법이 있음을 나타냅니다. 나는 또한 systemd-timesyncd.service
(구성 파일이 있음 /etc/systemd/timesyncd.conf
) 있다는 것을 깨달았고 timedatectl status
정확한 시간을 알려주었습니다.
Local time: Thu 2016-08-25 10:55:23 CEST
Universal time: Thu 2016-08-25 08:55:23 UTC
RTC time: Thu 2016-08-25 08:55:22
Time zone: Europe/Berlin (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2016-03-27 01:59:59 CET
Sun 2016-03-27 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2016-10-30 02:59:59 CEST
Sun 2016-10-30 02:00:00 CET
그래서 제 질문은 이 두 메커니즘의 차이점이 무엇입니까? 그 중 하나가 더 이상 사용되지 않습니까? 병렬로 사용할 수 있나요? NTP 동기화 상태를 쿼리하려면 어느 것을 신뢰해야 합니까?
(저는 다른 시스템(다른 네트워크에 있음)을 가지고 있으며 두 방법 모두 성공을 보여주고 정확한 시간을 생성합니다.)
답변1
systemd-timesyncd는 기본적으로 최신 systemd 버전과 어느 정도 번들로 제공되는 소규모 클라이언트 전용 NTP 구현입니다. 전체 ntpd보다 가볍지만 시간 동기화만 지원합니다. 즉, 다른 컴퓨터에 대해 NTP 서버 역할을 할 수 없습니다. 클라이언트 측에서 ntpd를 대체하기 위한 것입니다.
이론적으로 둘 사이에 약간의 지연이 있는 서로 다른 시간 서버를 선택할 수 있으므로 두 가지를 동시에 사용하면 안 됩니다. 이로 인해 시스템 시계가 주기적으로 "점프"하게 됩니다.
ntpdc
불행하게도 상태를 얻으려면 ntpd를 사용하는 경우 timedatectl
timesyncd를 사용해야 하며, 내가 아는 한 두 가지를 모두 읽을 수 있는 유틸리티는 없습니다.
답변2
systemd-timesyncd에는 시계 규칙이 없습니다. 시계는 훈련되거나 보상되지 않으며 시간에 따른 내부 시계의 드리프트는 줄어들지 않습니다. 폴링 간격을 조정하는 기본 논리가 있지만 제한되지 않으면 systemd-timesyncd가 최근 드리프트에 필요하다고 생각되는 간격으로 밀거나 당기기 때문에 호스트가 항상 고르지 않은 시간에 있게 됩니다. 또한 원격 시간 원본의 품질도 평가할 수 없습니다. 100밀리초 이상의 정확도를 얻을 가능성은 거의 없습니다. 이는 랩톱과 같은 간단한 최종 사용자 장치에는 충분하지만 더 높은 타이밍 정확도가 필요한 분산 시스템에는 확실히 문제를 일으킬 수 있습니다.