저는 ntpsec불안정한 데비안 버전을 사용하고 있습니다. 내 로그에는 다음이 표시됩니다.
Mai 22 11:48:34 services ntpd[13428]: CLOCK: time stepped by 1.442261
Mai 22 11:55:06 services ntpd[13428]: CLOCK: time stepped by 1.524066
Mai 22 12:03:00 services ntpd[13428]: CLOCK: time stepped by 1.702944
Mai 22 12:08:34 services ntpd[13428]: CLOCK: time stepped by 1.517894
Mai 22 12:17:38 services ntpd[13428]: CLOCK: time stepped by 1.434055
Mai 22 12:24:07 services ntpd[13428]: CLOCK: time stepped by 1.084220
Mai 22 12:32:29 services ntpd[13428]: CLOCK: time stepped by 1.562280
Mai 22 12:38:38 services ntpd[13428]: CLOCK: time stepped by 1.211420
Mai 22 12:43:49 services ntpd[13428]: CLOCK: time stepped by 1.185642
Mai 22 12:48:58 services ntpd[13428]: CLOCK: time stepped by 0.796154
Mai 22 12:54:43 services ntpd[13428]: CLOCK: time stepped by 1.331323
Mai 22 13:00:21 services ntpd[13428]: CLOCK: time stepped by 0.849190
이런 일은 오늘만이 아니고 며칠째 계속되고 있습니다. 분명히 ntpd시스템 시계 드리프트가 올바르게 수정되지 않았습니다. 항상 다음 이 있습니다 /var/lib/ntpsec/ntp.drift.
500.000000
내가 지금 시도한 것 :
- 커널이 RTC를 자동으로 업데이트하지 않도록 CONFIG_RTC_SYSTOHC를 비활성화합니다. 몇 시간 후
hwclock -w --update-driftRTC를 읽으려고 달려갔을 때 적어도 정확도가 더 좋아졌습니다. 드리프트 계수를 0.78초/일로 설정합니다. - 그 후, 나는
adjtimexconfig시스템 시계를 수정하기 위해 달려갔습니다(그게ntpd원래 해야 할 일입니다). 그것은 말한다:Comparing clocks (this will take 70 sec)...done. Adjusting system time by 275,531 sec/day to agree with CMOS clock...done.
ntpd그 결과 이제 많은 시간을 줄여야 하는 것 같습니다 .
Mai 22 14:24:20 services ntpd[13428]: CLOCK: time stepped by 0.234963
Mai 22 14:30:30 services ntpd[13428]: CLOCK: time stepped by 0.145163
좋아요 그런데 왜 ntpd직접 해보는 게 어때? 0.2초/6분은 아직은 너무 부정확한 것 같아서 이 과정을 몇 번 더 반복해야 할 것 같습니다. 어떤 제안이 있으십니까?
답변1
어떤 이유로 운영 체제 시계가매우부정확합니다. 정확한 시간은 일반적 ntpd으로 다음과 같이 유지 됩니다.돌아서 다즉, 느린 시계에 실시간을 따라잡기 위해 "속도를 높이도록" 지시하고, 실제로 실시간과 동기화될 때만 시계 속도를 실시간과 일치하도록 조정하고, 너무 동기화되면 시계 속도를 늦춥니다. 빠른.
그러나 운영 체제 시계의 경우 이 조정만으로는 충분하지 않은 것 같습니다. 오류가 너무 커서 ntpd단계 조정이 이루어져야 하며 본질적으로 시스템 시계를 몇 분마다 올바른 시간으로 재설정해야 합니다. 데이터베이스 등에 대한 정확한 타이밍을 원한다면 단계 조정을 완전히 피해야 합니다. 당신은해야아니요0이 아닌 단계 크기 조정에 만족하세요.
다행스럽게도 오류는 항상 같은 방향으로 나타나는 것으로 보아 조정이 가능한 체계적 오류일 가능성이 높습니다.
노트:이것이 가상 머신인 경우, 높은 부하로 실행되는 가상화 호스트와 사용량이 많은 VM을 실행하기 위해 유휴 VM에서 "시간을 훔치는" 시간 드리프트가 발생할 수 있습니다. 이 경우 먼저 가상화 호스트 관리자에게 권장되는 타이밍 수정 방법에 대해 문의하세요. 가상 머신이 본질적으로 타이밍을 위해 호스트 시계를 사용할 수 있도록 하는 "반가상화 시계" 옵션이나 호스트 솔루션 OS에서 권장하는 다른 옵션이 있을 수 있습니다. /하이퍼바이저 공급업체. NTP 동기화를 사용하려는 경우 가상화 호스트가 가상 머신의 시계를 방해하지 않는지 확인하십시오. 둘 중 하나만이 아니라 둘 중 하나만 방해하십시오!
hwclock -w --update-drift배터리 지원 RTC 클록의 드리프트는 배터리 지원 RTC 클록을 운영 체제 클록과 비교하여 추정되며, 귀하의 경우 이는 매우 부정확한 것으로 알려져 있습니다 . 따라서 알려진 불량 시계와 일치하도록 잠재적으로 좋은 시계를 조정하게 되는데 이는 좋은 생각이 아닌 것 같습니다.
adjtimexconfig반면, 배터리 구동 RTC가 정확하다고 가정하고 이에 맞게 운영 체제 시계의 매개변수를 조정합니다. 알려진 좋은 NTP 시간 소스에 액세스할 수 있는 경우 adjtimex --host <NTP server>운영 체제 시계를 NTP 서버와 직접 비교한 다음( ntpd이 작업을 수행하는 동안 중지) adjtimex -p결과 frequency와 tick값을 확인하는 데 사용해야 합니다.
또는 설정된 오프셋 값을 adjtimex -p확인하는 데 사용할 수도 있습니다 . 값만 조정되며 설정에는 전혀 영향을 미치지 않습니다.frequencyntpdntpdfrequencytick
주파수 오프셋 값이 +/-32768000 범위의 끝에 도달한 경우 tick수동으로 값을 조정하고 프로세스를 반복해야 합니다.
( frequency최대 양수 값에 도달하거나 접근하는 경우 도구가 시계 속도를 높이려고 하지만 조정 범위를 벗어났기 때문에 충분히 빠르게 속도를 높일 수 없는 것입니다. 이 문제를 해결하려면 값을 높이십시오 tick. frequency음수 한계에 도달하거나 접근하는 경우 , tick값을 줄입니다.)
tick주파수 오프셋 값을 상대적으로 중간 범위 값(예: 약 +/- 5000000)에 가깝게 유지하는 값을 찾으면 ntpd필요에 따라 주파수 오프셋 값을 조정하여 클럭을 동기화 상태로 유지할 가능성이 높아집니다. 눈금 값을 수동으로 편집 /etc/default/adjtimexconfig하고 adjtimex.service부팅 시 성공적인 실행을 보장해야 합니다. 부팅 전에 실행되므로 ntpdOS 시계는 "크루즈 제어" 역할을 시작하기 전에 "올바른 기어"로 설정됩니다.ntpd
OS 시계를 제어하면 ntpd동기화 상태가 유지되고( ntpq -np첫 번째 열에 별표가 표시됨) 부팅 시 한 번을 제외하고는 단계 조정에 대한 로그 메시지가 없으며 hwclock -w --update-driftRTC의 드리프트 속도를 사용하여 추정 할 수 있습니다. 시계. 최종 결과는 전원이 켜져 있든 꺼져 있든 합리적인 시간 동안 지속되는 시스템이어야 합니다.
답변2
아... adjtimexconfig그게 답이 아닐까? ! 이유가 무엇이든 위에서 수행한 작업으로 인해 ntpd쓰기 업데이트가 이루어졌습니다 /var/lib/ntpsec/ntp.drift. 지난 60분 동안 두 개의 메시지만 받았습니다.
Mai 22 15:59:45 services ntpd[13428]: CLOCK: time stepped by 0.241656
Mai 22 16:31:47 services ntpd[13428]: CLOCK: time stepped by 0.532398
지금은 꽤 만족하고 있는 것 같아요.
편집: telcoM 덕분에 이제 모든 답변과 솔루션을 얻은 것 같습니다. 먼저 무슨 일이 일어나고 있는지 설명하겠습니다. 10000은 분명히 초기 값입니다 tick. 내 시스템에서는 너무 느립니다. 그래서 ntpd시간에 맞춰 계속 밟아야 해요. ntp조정은 하지 않고 tick세밀한 조정만 하기 때문에 거리가 너무 멀면 frequency힘이 제한되어 아무것도 할 수 없습니다.tick
그것을 사용했을 때 adjtimexconfig문제가 해결되었지만 tickRTC에 따르면 정확하지 않았습니다. 10031로 설정되어 있는데 tick, 이는 여전히 너무 낮으므로 ntpd시간을 계속 뛰어넘어야 합니다. 이것이 바로 500.000000 /var/lib/ntpsec/ntp.drift( ntpd업데이트되지 않는 것 같음)에 머무르는 이유이며, 이는 빈도 32768000(드리프트 * 65536)과 동일합니다.
이제 adjtimex -t 10038문제를 해결 했으므로 tick갑자기 더 이상 메시지를 볼 수 없습니다 CLOCK: time stepped. ntpd현재 작업 중이므로 frequency: -1002503310037도 사용할 수 있다고 생각했습니다.